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R«port  on  Ada  T>K  and  evaluation 

1 .  Introduction 

In  Juno  of  1979,  following  an  extensive  procaaa  of  selection 
and  revision,  tha  Preliminary  Ada  language  definition  was  published. 
As  a  means  of  further  raflnlng  tha  language,  it  was  decldad  to 
approach  tha  prospactlva  usar  community  and  solicit  thalr  comments 
and  raactions.  This  raport  dascrlbes  tha  methods  usad  to  gathar  and 
avaluata  tha  many  rasponsas  received,"  and  dlscussas  tha  more 
prominent  Issues  raised. 


2.  Background 

There  ware  two  major  avenues  used  to  solicit  reactions.  The 
publication  of  tha  Preliminary  Ada  Reference  Manual  and  Rationale,  and 
Ada  newsletters  in  ACM  Slgplan  Notices,  the  major  Informal  journal  on 
programming  languages,  assured  wide,  circulation  of  the  language 
definition  and  requests  for  comments. 

The  other  major  and  more  formal  source  of  comments  was  tha 
Teat  and  Evaluation  reports.  Military  organizations,  defense 
contractors,  and  the  computer  industry,  were  asked  to  analyze  existing 
applications  programs,  possibly  reprogram  them  in  Ada,  and  raport 
thalr  axparlanca.  A  few  outside  the  military  and  its  contractors  also 
submitted  such  reports. 

Tha  High  Order  Language  Working  Croup  (HOLWG)  appointed  a 
•Jl  of  experts  on  programming  languages,  termed  tha  Ada 
Distinguished  Reviewers,  to  oversee  the  review  of  these  comments  and 
further  discuss  language  Issues  in  order  to  assist  the  language  design 
team  at  CII-Honeywell-Bull  In  Its  refinement  effort.  Intermetrics,  Inc. 
was  contracted  to  coordinate  comment  processing  and  to  support  the 
Distinguished  Reviewers  administratively .  This  program-  was 
Intermetrics  Test  and  Evaluation. 

The  functions  of  the  Intermetrics  Test  and  Evaluation  program 
have  changed  with  the  needs  of  the  Distinguished  Reviewers.  Initially, 
it  was  thought  to  be  most  productive  for  Intermetrics  to  prepare 
position  papers  (Draft  Change  Requests),  discussing  controversial 
Issues  and  proposing  changes  which  would  then  be  discussed  by  the 
Distinguished  Reviewers.  If  accepted  by  the  Reviewers,  the  proposals 
would  be  passed  along  to  HOLWG  for  possible  approval  an  Language 
Change  Requests. 
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This  approach  proved  too  rigid,  as  it  put  the  language  design 
teae  and  the  Distinguished  Reviewers  in  an  adversary  relationship.  In 
subsequent  Reviewers*  Meetings,  Intermetric*  did  not  present  position 
papers,  but  instead  continued  to  prenare  documents  useful  for  the 
Reviewers.  These  documents  fore  the  core  of  this  report. 

In  addition  to  technical  and  administrative  support, 
Intereetrics  perforaed  soae  general  analyses  on  the  Test  and 
evaluation  docuaents.  The  results  of  the  analyses  were  presented  at 
the  Paris  nesting  to  the  Distinguished  Reviewers;  their  revised  and 
updated  versions  are  found  within. 

Intereetrics  also  provided  continuing  support  Cor  the  Test 
and  Evaluation  process  by  serving  as  the  clearinghouse  for 
information  and  docuaents.  Numerous  inquiries  concerning  certain 
aspects  of  the  language — from  details  of  the  syntax  to  questions 
about  its  future  importance  to  computer  science — were  received  by 
traditional  and  Arpanet  mall,  telephone,  personal  visits,  and  chance 
meetings.  These  were  answered  and  docuaents  were  sent  as 
appropriate. 


3 .  Ada  Test  and  Evaluation  Reports 

In  addition  to  input  froa  language  designers  and 
theoreticians,  the  Test  and  Evaluation  process  considered  the 
opinions  of  system  and  application  software  developers. 

Defense  Department  sites  and  contractors  were  asked  to  study 
their  existing  applications  and  select  one  to  reprogram  in  Ada.  The 
results  of  their  experience  are  found  in  the  Test  and  Evaluation 
Reports.  The  elqhty-two  TER's  represent  a  broad  spectrum  of  experience 
on  the  part  of  the  participants. 

A  TER  comprises  two  parts.  The  primary  section  contains  a 
questionnaire,  composed  by  DoD,  which  addresses  the  participant’s 
experience  with  and  reaction  to  using  Ada  in  an  applications  context. 
Additionally,  the  primary  section  often  contains  an  algorithm  written 
in  both  a  language  normally  used  by  the  participant,  and  in  Ada.  Along 
with  these  comparison  programs  are  usually-  mors  extensive  comments 
dealing  with  Issues  that  were  beyond  the  scope  of  the  questionnaire. 

The  supplementary  section  varies  in  nature  and  contents  with 
each  report.  Many  participants  included  system  and  language  reference 
manuals  in  addition  to  the  source  code  in'  order  to  fully  present  their 
appl lcatlons. 

To  syrteaatlxe  their  dissemination,  the  TEA'S  were  numberad 
and  separated  into  their  primary  and  supplementary  sections.  The 
primary  section  carries  e  TER  number  only;  the  eupplementery  sections 
carry  the  TER  number  and  a  suffixed  section  letter.  The  supplementary 
material  was  further  separated  Into  original  coda  sections  (containing 
coda  written  In  the  original  languaga) ,  and  Ada  code  sections  (which 


contained  tha  Ada  translation)  in  order  to  facilitate  distribution  of 
Ada  code  samples  to  thoss  wishing  to  analyze  then.  Appendix  E 
indicates  tha  languages  used  in  these  code  comparisons. 

Since  the  Test  and  Evaluation  Reports  were  not  submitted  in 
machine-readable  form,  and  their  volume  precludes  entry,  they  are  not 
on  line.  The  derived  files  produced  during  the  Intermetrics 
analysis,  however,  are  all  on  line,  and  are  described  in  the 
Appendixes. 


4.  Analytical  methods 

Given  the  form  and  content  of  the  TER's,  borne  method  was 
needed  to  summarize  tha  useful  information  they  contained.  One 
possible  technique  would  have  been  to  summarize  each  TER  separately 
and  report  its  contents  without  any  evaluation.  This  would  faithfully 
preserve  tha  contents  of  the  Individual  TER's  and  would  be  the  manner 
lease  influenced  by  the  summarization.  However,  it  would  not  help  the 
language  review  process  since  It  does  not  address  the  difficulties  in 
understanding  Ada,  and  the  differences  in  training  and  experience 
among  the  Test  and  Evaluation  participants. 

Alternatively,  the  TER's  could  be  analyzed  into  lasues,  as 
were  the  t-lR's.  This  would  be  unsatisfactory  as  the  TER's  take  quite  a 
different  approach  to  problems  than  do  the  LIR's:  rather  than  study 
language  issues,  the  TER's  deal  with  language  applications. 

In  order  to  avoid  the  problems  described  above,  verbatim 
extracts,  a  topical  cross-reference,  and  a  presentation  of  the 
conclusions  drawn  by  the  TER  analysis  were  prepared. 


5.  Findings 


5 . 1  Extracts 

So  that  the  language  teas  and  outside  evaluators  might  gain 
insight  into  the  participants  individual  reactions  to  Ada,  verbatim 
extracts  from  the  TER's  were  compiled  to  preserve  the  original 
phrasing  and  tone,  which  would  otherwise  not  be  accessible  to  those 
unable  to  sift  through  the  thousands  of  pages  which  comprise  the 
original  reports. 

The  extracts  were  chosen  and  abridged  to  present  a  balanced 
view  of  each  report.  Comparisons  in  the  extracts  refer  to  the 
original  implementation  language,  so  that  the  phrase  *Ada  is  more 
debuggable*  means  *Ada  is  more  debuggable  than  our  current  language*. 
The  extracts  are  not  intended  to  reflect  difficulties  in  understanding 
the  preliminary  manual  or  the  languages  these  Issues,  are  of  central 
con -am  to  writers  of  manuals  and  expository  treatments,  difficulties 
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in  understanding  the  language  will  also  Manifest  themselves  in  the 
detailed  technical  summaries.  Extracts  were  not  taken  from  sections 
of  the  TZR's  where  the  participants  indicated  that  they  did  not  fully 
understand  the  language  or  the  eanual,  as  it  is  not  clear  how  to 
Interpret  such  answers  in  the  context  of  language  changes.  Comments 
relating  to  concerns  of  coapiler  quality  (i.e.  degree  of  optimization , 
speed,  size,  etc.],  developeent  environment,  organizational  problems, 
and  the  like  were  siaiiarly  not  included  In  this  sample.  (i'he 
extracts  used  in  the  analysis  are  found  in  Appendix  F.) 


5.2  language  Comparison 

A  review  of  the  TER's  shows 
participants  ara  heavily  Influenced 
this  fact,  some  general  responses 
respondent's  previous  language. 

5.2.1  Assembly  language 

Not  surprisingly,  assembly 
control  over  object  program  and  data 
tasking  and  abstraction  mechanisms 
them  as  Inefficiently  Implemented  in 


that  many  conclusions  drawn  by 
by  their  experience.  In  light  of 
to  Ada  are  categorized  by  the 


language  programmers  emphasize 
Many  praise  such  facilities  as 
n  one  breath,  only  to  criticize 
the  next. 


Specific  features  desired  by  this  group  are  static  allocation 
of  data,  unsafe  pointers,  and  representation  specif icationa. 

The  most  important  factor  in  the  acceptance  at  Ada  by  tnls 
group  will  be  the  availability  of  compilers  which  use  time  and  space 
efficiently.  The  assembly  language  programmers  do  not  believe  It  can 
be  done. 


5.2.2  fortran 


fortran  programmers  comment  favorably  on  the  presence  of 
structured  programming  constructs  such  as  If. ..TREK. ..ELSE  and  loops. 
There  is  a  definite  split  in  opinion  about  GOTO'ss  some  maintain  they 
are  Important;  others  would  like  to  eliminate  them  from  the  language 
entirely  in  order  to  encourage  better  programming  style.  It  is  not 
clear  whether  this  argument  is  based  on  experience  or  current  trends. 

One  fortran  feature  missed  is  formatted  I/O.  If  a  formatted 
I/O  facility  is  not  standard,  will  there  exist  such  a  capability  for 
every  machine?  Will  the  facilities  for  various  machines  be 
compatible?  Can  a  formatted  I/O  facility  be  written  efficiently 
using  an  Ada  package? 


5.2.3  PL/I 
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PL/I  prograr  --s  prefer  PL/I’s  model  of  storage  allocation 
types  In  which  there  ,  an  explicit  choice  of  allocation  method  at 
the  allocation  of  each  variable.  The  parallel  *baaed  variable* 
facility  is  also  missed. 

Source  inclusion  is  sometimes  preferred  to  the  package  and 
separate  compilation  facility.  Of  course,  source  inclusion  does 
exist  in  Pda  through  the  Include  pragma. 

5.5.4  Algol-Ilka  languages 

Among  the  Test  and  Evaluation  participants,  there  is  a  fairly 
sizable  contingent,  primarily  from  England,  using  Algol-like  languages 
in  embedded  applications.  This  group  mlsseu  high-level  Algol 
constructs  more  than  lower  level  constructs.  Additionally,  conaitlonal 
expressions  and  functional  arguments  are  repeatedly  mentioned  as 
useful  and  efficient.  It  is  not  clear  from  the  TER  comments  whether 
the  revised  Ada  generics  would  satisfy  the  request  for  functional 
arguments. 


5, 3  Major  Issues 

This  section  identifies  the  major  Issues  which  have  been 
raised  by  Ada  Test  and  Evaluation  participants.  For  ease  of 
exposition,  the  Issues  have  been  grouped  into  seven  categories: 

1.  Tasking 

2.  Program  Structure,  Name  Resolution  and  Separate  Compilation 

3.  Predictability  and  Efficiency  of  Object  Code 

4.  Values  and  Expressions 

5.  Abstraction  and  Extensibility 

6.  Language  Phise-tn 

7.  Syntax 


5.3.1  Tasking  Issues 

The  TER  reports  present  a  variety  of  real-time  applications 
requiring  tasking.  While  many  participants  implemented  their 
real-time  applications  successfully  in  Ada,  others  were  unable  to  do 
so.  The  crucial  question  is  whether  this  inability  was  due  to 
shortcomings  in  the  language,  or  to  Inadequate  education  in  the  use 
of  Ada  for  such  appl ications. 

The  difficulties  which  Test  and  Evaluation  participants  had 
in  applying  the  talking  model  to  applications  prompted  both  the 
Distinguished  Reviewers  and  the  Language  Design  Team  to  examine  the 
existing  model.  The  Revised  Ada  tasking  model  will  be  substantially 
the  same,  but  with  some  important  extensions  and  changes  resulting 
from  the  Test  and  Evaluation  process. 
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The  Ada  talking  nodal  differs  radically  fron  nany  previous 
applications  languages  In  that  it  recognizes  tasks  explicitly  and  has 
a  well-defined  notion  of  task  connunlcatlon  and  synchronization 
through  the  concept  of  the  rendezvous.  Careful  education  In  the  use 
of  Ada  tasking  and  re-analysls  of  applications  will  be  needed. 

It  should  be  noted  that  although  features  of  Ada  tasking  were 
rather  extensively  criticized,  and  that  nany  of  these  criticisms  led 
to  language  changes,  the  Ada  tasking  aechanisn  as  a  whole  was  often 
mentioned  as  a  particularly  strong  feature  of  the  language.  Fully 
fourteen  of  the  TER 1 s  praised  tasking  explicitly. 


The  following  is  a  detailed  account  of  the  major  concerns 

expressed: 

5. 3. 1.1  — Ada  tends  to  encourage  and  sometimes  require  programmers  to 

define  more  tasks  than  they  wo'ild  in  other  languages,  and 
there  is  a  concern  that  this  wl.l  result  in  excessive 
overhead,  specifically  in  the  areas  of  scheduling  and  context 
switching.  T'CLOCK  is  a  minor  issue  in  this  discussion  some 
say  it  must  be  supported  since  it  cannot  be  implemented 
within  the  language,  and  others  that  It  incurs  unavoidable 
and  unacceptable  overhead.  The  ability  to  pass  arguments  to 
tasks  at  creation  is  another  specific  request  reLated  to 
tasking  efficiency.  It  has  been  asserted  that  the 

Kabernann-Nassi  optimization  answers  the  efficiency  concern. 
However,  there  are  questions  about  how  to  tell  when  it  can, 
should,  or  will  be  used,  so  some  reviewers  remain  skeptical. 

5.3.1.2  —Preliminary  Ada  does  not  at  this  point  provide  sufficient 

control  of  scheduling  decisions,  specifically  the  assignment 
of  tasks  to  available  physical  processors  (or  virtual 
processors  In  a  time-shared  environment).  Thfs  area  will 
have  a  major  impact  on  Ada's  use  in  real-time  systems  and  for 

systems  programming.  Some  want  the  scheduling  points  to  be 

precisely  defined,  to  be  able  to  explicitly  suspend  and 

resume  tasks,  or  to  be  assured  that  scheduling  is  "fair",  cr 
both. 

5. 3. 1.3  —the  scheduling  rulss  do  not  guarantee  thee  hardware 
interrupts  wil)  cause  the  timely  execution  of  the 
corresponding  interrupt  handler. 

5.3.1.4  —The  mechanisms  for  sharing  data  between  tasks  seem  overly- 
involved  to  people  who  are  used  to  having  a  mechanism  for 
representing  synchronization  information  as  data. 

5.3.1.5  —Many  people  want  to  be  able  to  determine  task  names  during 
program  execution.  For  example,  *  server  task  might  be  doing 
work  for  several  other  tasks  and  need  to  determine  which  one 
has  just  been  tha  partner  in  a  rendezvous.  People  have  also 
wondered  how  to  terminate  an  orrant  task  if  they  can’t  name 
it.  There  is  substantial  support  for  the  idea  of  having  TASK 
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as  a  built-in  typa  In  the  language  as  a  solution  to  these 
problems. 

5.3.1. $  — Soma  paopla  have  asked  for  a  capability  to  dynamically 

create  and  delete  tasks  at  run-time. 

S.3.1.7  —Some  people  are  concerned  about  the  asymmetry  in  the 
CALL— ACCEPT  model  for  invoking  task  entries.  The  writer  of  a 
task  can  prevent  it  from  waiting  indefinitely  to  be  called  by 
using  the  SELECT  and  DELAY  statement;  but  the  writer  of  the 
task  making  the  entry  call  has  no  equivalent  capability. 
Conditional  and  timed  entry  calls  are  desired. 

5. 3.1.  ft  —There  may  be  problems  associated  with  the  handling  of 

possible  error  conditions  that  can  arise  when  one  of  the 
partners  to  a  rendezvous  has  died. 

5. 3. 1.9  —The  requirement  for  hierarchies  of  tasks  as  provided  by 
current  Ada  has  not  been  demonstrated.  Both  users  and 
implementors  have  expressed  a  desire  for  restrictions  in  this 
area  to  reduce  complexity.  Task  hierarchies  also  may  create 
problems  In  the  Interaction  between  task  termination  and 
scope  exit. 

5.3.1.10  — The  requirement  for  one  task  to  be  able  to  change  another 

task*s  priority  has  not  been  justified.  Some  people  have 
pointed  out  that  the  ability  to  change  priorities  can  be 
misused  as  a  synchronization  mechanism  and  should  be 

eliminated.  The  ability  of  a  task  to  terminate  its  parent 
has  also  been  objected  to. 

5.3.1.11  —Although  the  tasking  model  itself  is  clean  and  simple,  it 
is  not  always  obvious  how  to  apply  it  to  problems  which  have 
been  previously  solved  in  other  ways.  This  proved  to  be  a 
difficulty  expressed  in  several  TER's.  The  concept  of  buffer 
task,  for  Instance,  although  explained  in  the  language 
documentation,  is  not  easy  to  grasp— Indeed,  it  appears  to  be 
inefficient  at  first  glance.  However,  Habermann  and  Nassl 
have  shown  that  the  use  of  buffer  tasks  does  not  imply  that 
they  must  be  scheduled  separately  from  the  tasks  they 
service. 

5.3.1.12  —Many  TER's  requested  that  task  priorities  be  strictly 
enforced,  and  that  the  scheduling  algorithm  be  well-defined. 
The  lack  of  definition  of  scheduling  strategy  left  many 
participants  unable  to  define  solutions  to  their  applications 
problems.  One  difficulty  with  strict  priorities  is  the 
possibility  that  they  might  be  used  as  synchronization 
mechanisms,  defeating  many  of  the  advantages  of  tha  tasking 
model.  Although  forbidding  this  is  unenforceable,  on  the 
balance  it  was  decided  that  strict  priorities  were  in  fact 
needed  in  the  language.  As  for  the  scheduling  algorithm,  the 
decision  to  adopt  strict  priorities  partially  defines  it;  the 
definition  of  scheduling  points  in  revised  Ada  further 


defines  it.' 

5.3.1.13  —The  semantics  of  Preliminary  Ada  lntarrupta  war*  oftan 
aantlonad  as  lnadaquata,  as  they  lapliad  queuing  of 
Interrupts  rather  than  providing  Immediate  service. 
Interrupts  in  Revised  Ada  will  correspond  closely  to  the 
traditional  notion. 

5.3.1.14  — Where  previous  tasking  models  deal  in  low-level  operations 
and  explicit  suspension  and  resumption  of  tasks,  applications 
programs  written  in  those  tarns  cannot  be  easily  translated 
into  Ada.  Some  TER’s  request  these  facilities  in  Ada,  but  It 
lr  not  clear  whether  they  are  functionally  necessary. 


5.3.2  Program  Structure,  Wane  Resolution,  Separate  Compilation, 
and  Related  Issues 


Another  area  of  concern  Is  a  perception  that  the  mechanisms 

Preliminary  Ada  provides  for  structuring  programs  are  unnecessarily 

rich,  and  hence,  complex  from  the  perspective  of  both  users  and 

Implementors. 

5. 3.2.1  — Some  rules  In  the  manual  (e.g.,  no  aliasing)  would  require  a 
complete  pass  through  the  entire  system  (a  transitive 
closure)  to  check.  Such  a  check  could  make  separate 
compilation  Impractical,  i 

S.3.2.2,  — Some  people  are  concerned  about  the  complexity  of  the 
overloading  resolution  rules.  For  example,  the  interaction 
of  renames  with  the  ability  to  change  discriminants  has  been 
mentioned.  The  design  team  has  already  decided  that 
parameter  modes  are  not  a  sufficiently  strong  criterion  for 
overloading  resolution,  and  that  parameter  names  are  not  an 
appropriate  criterion  for  overloading  operators.  It  has  been 
argued  (persuasively)  that  overloading  resolution  with 
optional  named  parameters  Is  a  computation  exponential  in  the 
number  cf  parameters. 

5.3.2.3  — Users  have  difficulty  understanding  the  multiple  mechanisms 
for  structuring  a  program. 

5. 3. 2. 4  —Some  users  have  difficulty  understanding  the  combination  of 
USE,  RENAMES ,  and  RESTRICTED.  Examples  (both  good  and  bad) 
used  in  these  debates  are  often  library  packages  which 
contain  large  name  spaces. 

5. 3. 2. 5  — Problems  can  arise  when  packages  call  other  packages  during 
Initialization.  It  is  not  clear  how  the  compiler  must 
determine  a  workable  initialization  order  (it  could  be 
expensive)  or  how  the  user  can  specify  the  order. 
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5. 3. 2. A  --Soma  people  have  objected  to  the  private  part  of  the  module 
specification  on  both  methodological  and  practical  grounds. 

5.3.2.7  — The  language  currently  does  not  require  compile  time 
evaluation  of  static  expressions.  This  means  that  some 
compilers  will  detect  errors  at  compile  time  and  others  at 
run-time. 

5.3.2.8  — Several  peopia  have  asked  that  a  conditional  compilation 
capability  be  added  to  the  language. 

5. 3. 2. 9  --Many  Important  optimizations  only  work  In  the  absence  of 
aliasing,  but  aliasing  can  only  be  detected  with  a  transitive 
closure  computation.  The  language  definition  should  take  a 
position  on  the  validity  of  optimizations  which  depend  on  the 
absence  of  aliasing.  Also,  some  kinds  of  aliasing  are  useful 
(and  safe) .  A  mechanism  is  under  consideration  to  allow  the 
programmer  to  specify  as  part  of  a  procedure  or  entry 
declaration  that  the  procedure  has  been  written  to  produce  a 
correct  result  even  if  actuals  are  aliased  through  binding  to 
formats.  Aliasing  of  globals  passed  as  parameters  would 
still  be  an  error  in  all  cases. 


S.3.3  Predictability  and  Efficiency  of  Object  Code 


One  goal  of  Ada  optimizing  compilers  is  to  generate  coda  that 
is  competitive  with  machine  code  handwritten  by  a  skilled  system 

programmer.  This  section  discusses  several  efficiency-related  issues 
for  sequential  Ada. 

S.3.3.1  —Preliminary  Ada  specifies  efficient  parameter  passing  with 
some  sacrifice  of  safety  and  portability  In  three  special 
cases:  variables  shared  between  tasks,  exceptions,  and 

aliasing.  Explicit  copies  must  be  made  to  prevent  variables 
from  being  shared  between  tasks,  the  state  of  OUT  and  INOUT 
actuals  is  indeterminate  If  the  exit  Is  caused  by  an 

exception,  and  aliasing  Is  Illegal. 

A  typical  Implementation  allows  the  calling  program  to 

pa33/return  small  objects  in  registers  or  on  the  stack  and 
to  pass  reference  pointers  to  larger  objects.  Great  care 
must  be  taken  in  reference  Implementations  for  INOUT  and  OUT 
parameters  when  the  actuals  are  more  tightly  constrained  than 
the  formals;  an  Incorrect  Implementation  could  result  In 
assigning  an  Illegal  value  to  the  actual  which  overwrites 
adjacent  memory.  An  Incorrect  implementation  could  also 
leave  an  Incorrect  value  in  the  actual  after  an  exception. 


llliiBi  ilffltfWH*****'*  — - -  '  I,-.,.  ...  .  — — - 
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Soma  of  tha  criticism  of  preliminary  Ada's  parameter  passing 
mechanisms  comas  from  a  mistaken  belief  that  it  Is  less 
efficient  than  reference  passing. 

Other  criticism  comes  from  people  who  object  to  the  fact  that 
a  programmer  can  determine  whether  the  compiler  .  which 
implements  a  particular  call  be  reference  or  by  copy,  and 
exploit  that  fact  to  write  nonportable  programs.  Most  people 
who  Insist  on  precisely  defined  semantics  want  pure  copy 
semantics)  they  have  not  been  able  to  convince  the  people  who 
are  primarily  concerned  with  efficiency  that  large  objects 
can  be  safely  passed  by  reference  while  guaranteeing  copy 
semantics  and  without  a  transitive  closure  analysis. 

5. 3. 3. 2  —Users  are  confused  by  the  distinction  between  functions  and 
value  returning  procedures.  The  current  definition  of 
function  seems  not  to  allow  desired  optimizations,  seems  to 
outlaw  'benevolent*  side-effects  (e.g.,  garbage  collection, 
instrumentation) ,  '  and  requires  a  transitive  closure 
computation  to  check. 

A  popular  proposal  Is  to  allow  value  returning  procedures 
full  functional  notation  and  be  usable  wherever  a  value  of 
the  type  is  required.  Under  this  schema.  It  would  be 
acceptable  to  eliminate  pure  functions.  A  declaration  might 
be  provided  as  part  of  the  value  returning  procedure 
declaration  to  specify  that  calls  nay  optimized  under  the 
assumption  of  abstract  functionality. 

5. 3. 3. 3  — Some  people  are  concerned  that  Ada  will  force  programmers  to 
use  dynamic  storage  allocation  and  require  the  run-time 
system  to  do  garbage  collection.  Garbage  collection  is 
unacceptable  in  many  real-time  systems.  Examples  of 
capabilities  which  have  been  requested  to  overcome  these 
Inefficiencies  are  explicit  Allocate  and  Free  mechanisms  and 
pointers  to  static  data. 

$.3.3.4  — Some  participants  In  the  T&E  analysis  have  asked  that  the 
language  provide  an  explicit  overlay  capability.  There  does 
not  seem  to  be  any  way.  to  write  such  a  facility  in  Ada 
without  a  primitive  operation  which  says  'execute  this  data 
as  code". 

5.3.3.5  ~A  much  more  robust  set  of  standard  implementation  parameters 
is  needed.  For  example,  memory  size,  storage,  remaining 
stack  storage,  target  machine,  word  size. 

5. 3. 3.6  — Many  people  have  criticized  the  UNSAFE_PROG RAMMING  feature 
of  the  language.  In  part,  the  problem” is  the  name,  which 
implies  that  the  use  of  the  facility  is  inappropriate, 
whereas  it  is  in  fact  the  only  way  to  implement  some  very 
important  operations  such  as  the  mapping  of  Input  data  into  a 
typed  variable.  One  reviewer  has  stated  that  the  language 
should  have  exactly  one  such  feature,  and  UNSAFE  PROGRAMMING 
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Is  the  correct  on*.  Others  hav*  suggested  that  there  are 
degrees  of  unsafeness,  and  that  really  dangerous  operations 
such  as  turning  an  integer  into  a  pointer  should  be 
distinguished  from  safer  kinds  of  type  conversion. 


5.3.4  Values  and  Expressions 

A  variety  of  issues  have  been  raised  with  respect  to 
variables,  values,  expressions  and  the  Initial  values  of  variables. 
Sob*  of  these  are  ainor,  and  hav*  already  been  addressed  in  language 
changes  under  consideration.  For  exaaple,  HO_VALUE_ERROR  will  be 
eliminated,  a  private  type  will  be  defined  for  time,  Ov*rlap_*rror 
will  be  eliminated,  the  Underflow  exception  will  be  eliminated, 
exceptions  occurring  during  the  elaboration  of  declarations  will  be 
passed  to  the  containing  scop*,  the  NOD  function  will  hav*  the 
conventional  definition,  and  qualification  will  be  required  for  on*  - 
component  aggregates. 

5. 3. 4.1  — Several  LtR's  request  the  capability  to  initialize  parts  of 
aggregates.  With  the  deletion  of  NO_VALUE_ERROR,  this 
capability  seems  reasonable  and  desirable.  ~ 

5. 3. 4. 2  — Some  people  want  pointers  initialized  to  NULL,  others  want 
them  Initialized  to  an  Illegal  value  (i.e.  not  NULL).  Others 
point  out  that  such  automatic  initialization  would  introduce 
a  non-uniformity  into  the  language.  The  language  change 
under  consideration  suggests  initialization  to  NULL. 

5. 3. 4. 3  — People  hav*  had  trouble  understanding  type  derivation  and 
type  conversion. 

5. 3. 4. 4  — Nany  LIR's  suggest  changes  to  the  built-in  numeric  types, 
especially  fixed  point. 

5. 3. 4. 5  —The  language  does  not  contain  a  built-in  “SET*  type  as 
required  by  Steelman.  The  notation  for  bit  string  constants 
is  presently  somewhat  awkward. 

5. 3. 4.  A  — Nany  people  hav*  requested  more  convenient  capabilities  for 

handling  variable  length  strings. 

5. 3. 4. 7  — Some  people  hav*  asked  to  be  able  to  specify  default  initial 
values  with  type  definitions. 

5.3.4. R  — Implementation  dependencies  can  arise  in  certain  cases 

because  the  language  does  not  define  a  semantic  order  of 
evaluation  for  expressions,  and  does  not  specify  the 
mathematical  properties  of  operators  which  can  be  assumed. 
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5.3.5  Abstraction  and  Extensibility 

Ada  baa  advanced  capabllitlaa  for  defining  new  data  types  and 
operations  and  for  defining  generic  procedures.  These  abstraction  and 
extensibility  features  set  Ada  apart  fro*  existing  programing 
languages  for  embedded  systems.  They  are  also  the  focus  of  sosie  of 
the  aost  active  debates  In  language  Issue  and  TER's.  This  section 
summarizes  soae  of  the  sain  topics  of  debate. 

5. 3.5.1  --In  preliminary  Ada,  the  eguallty  operation  for  record  and 

array  types  Is  defined  In  terms  of  the  predefined  eguallty  of 
the  component  types.  When  the  user  has  the  possibility  of 
redefining  equality,  this  may  lead  to  strange  anomalies.  The 
problem  of  assignment  for  composite  types  is  akin  to  thac  of 
equality,  though  less  acute  because  assignments  are  not  user 
definable.  r  - 

5. 3. 5. 2  —It  has  been  suggested  that  parameters  should  be  named  when 
overloading  a  function,  and  that  the  same  overloading  rules 
should  be  used  as  for  generics. 

5. 3. 5. 3  —There  Is  no  way  to  set  discriminants  (e.g.  array  bounds  or 
variant  record  selectors)  of  private  types  at  run-time, 
because  the  component  nanea  are  not  visible.  A  ‘limited 
window  Into  private  types*  mechanism  Is  under  consideration 
which  would  allow  the  programmer  to  specify  that  sons  of  the 
discriminants  embedded  In  a  private  type  are  externally 
settable  at  initialization  time. 


5. 3. A  Language  Phase-In 

A  variety  of  Issues  have  been  raised  regarding  Interfaces  to 
other  languages,  Interfaces  to  existing  operating  systems, 
representation  of  external  interfaces,  and  lnput/”>utput  packages. 
While  these  will  have  a  major  Impact  on  the  acceptance  ot  the  language 
and.  In  particular,  on  how  quickly  It  will  come  Into  widespread  use, 
they  are  the  responsibility  of  the  environment  rather  than  the 
language.  The  one  language  change  currently  identified  as  addressing 
the  above  Issues  is  to  have  the  visible  part  of  a  nodule  specify  the 
relevent  language  processor  if  the  body  consists  of  foreign  code. 


5.3.7  Syntax 
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A  large  number  of  coaMnti  on  the  language  syntax  have  been 
received,  aost  frequently  asking  aention  of  such  issues  as  naae  or 
keyword,  the  position  of  semi-colon,  peraaeter  association,  and  the 
like.  It  is  recommended  that  these  be  studied  carefully  after  the 
language  seaantlcs  have  been  finalized.  The  goal  of  standard  Ada 
syntax  should  be  readability  for  docuaentatlon  purposes  and  for  use  in 
publishing  algorithms.  It  is  assumed  that  software  tools  such  as 
language  oriented  text  editors  will  be  used  to  simplify  the  writing 
and  entry  of  Ada  programs. 


*•  Difficulties  in  Interpretating  the  TEAS 

Some  of  the  material  in  the  TER's  was  discounted  because  of 
jdmitted  or  obvious  misunderstandings  of  the  language.  It  was  not 
always  possible  to  consult  individually  with  participants  when  they 
had  problems,  misunderstandi ngs  or  had  missed  points.  The  root  of  the 
problem  may  lie  in  the  fact  that  the  preliminary  language  manual  was 
not  a  tutorial  document,  and  that  those  tutorial  documents  which  were 
available  did  not  examine  all  aspects  of  the  language,  visibility, 
for  example,  was  one  area  widely  misunderstood  in  the  LR*.  However, 
TER's  which  reflected  some  confusion  or  misunderstanding  ultimately 
played  an  important  role  in  evaluating  Ada,  as  they  helped  pinpoint 
areas  of  ambiguity. 

Many  of  these  problems  in  understanding  the  language  arose 
when  the  partlclpent  wes  required  to  use  mutually  Interactive 
features.  However,  this  is  precisely  the  sort  of  problem  covered 
rather  extensively  in  the  LIR's;  thus  the  TER's  and  HR's  complement 
one  another. 

Other  material  which  had  to  be  discounted  in  the  TER's  was  the 
body  of  comments  pertaining  to  the  efficiency  of  various  language 
features.  Although  it  is  eurtainly  true  that  certain  constructs  can 
be  shown  to  have  Intrinsic  inefficiencies,  and  that  efficiency  is 
essential  in  many  embedded  applications,  the  TER's  often  do  not 
identify  what  function  suet  be  performed  efficiently,  but  rather 
Indicate  that  a  particular  implementation  of  that  function  might  be 
expected  to  compile  poorly  Ltlng  the  compilers  familiar  to  the  TER 
writer. 


The  underlying  application  requirements  in  a  TER  often  become 
difficult  to  interpret  ;nen  the  writer  presents  his  or  her  own 
language  solutions  rather  than  working  within  the  framework  of  the 
desired  functionality.  For  instance,  meny  TER's  request  static 
allocation-  of  variables  as  a  language  feature,  apparently  for  time 
efficiency  and  ease  during  debugging.  It  is  possible  that  with  modern 
compiler  technology,  non-static  allocation  could  be  more  efficient 
without  compromising  debugging.  This  is  a  language  and  compiler 
design  natter.  Vn  this  case,  the  functionality  desired  is  fairly 
clear,  and  the  natter  has  been  discussed  at  meetings  of  the 
Distinguished  Reviewers. 


7.  Mandates  for  Chang* 


In  some  areas,  th*r*  was  great  unanimity  of  opinion  about 

necessary  language  changes.  These  are  presented  below  with 

Indications  of  design  teas  actions. 

7.1  — Sob*  way  of  guaranteeing  exact  fixed-point  representation  is 

desired.  The  approximate  fixed-point  systea  of  Preliminary 
Ada  does  not  suffice  for  aany  applications.  Exact 
fixed-point  arithaetlc  also  Is  desired.  These  concerns  sight 
be  answered  either  through  a  change  to  fixed  point  or  a 
desonstration  that  the  applications  requirements  can  be  met 
through  the  writing  of  packages.  The  Language  Design  Teas  is 
revising  fixed-point. 

7.2  —The  syntax  of  the  case  stateaent,  ‘Case  ...  of  when  ...*  is 
widely  disliked  as  not  reseabling  English.  The  seaantics 
appear  to  be  satlsfactcry,  but  the  syntax  will  be  changed. 

7.3  -Variable-length  strngs  are  needed,  again  either  through  the 
language  or  through  definable  libraries.  The  Distinguished 
Reviewers  and  the  Language  Design  Teas  have  studied  this 
eatter  carefully,  and  will  aeet  the  need. 

7.4  —A  aor*  coaplet*  I/O  package  is  desired  which  would  include 
aultlpl*  data  types  per  file,  Portran-llk*  formatting 
functions,  and  aor*  functions  in  the  standard  package.  This 
requirement  can  currently  be  set  with  the  package  aeehanisa. 
To  what  extent  a  larger  standard  I/O  package  should  be  part 
of  the  'anguage  and  not  the  environment  is  still  an  open 
issue. 

7.5  —True  Interrupts  are  needed.  Revised  Ada  will  have  them. 

7.«  — Many  TER's  request  "bitstrlngs*.  This  is  a  very  widespread 

demand,  but  it  is  not  clear  what  functionality  is  desired  in 
using  bltstrings  The  Preliminary  Ada  Unsaf*_Converslon 
function  (now  renamed  to  Unchecked  Conversion)  can  certainly  . 
convert  between  Integers  and  packed  arrays  of  boolean*, 
packed  arrays  of  boolean*  themselves  can  represent  sets. 
.Thus  the  bitstring  representation  of  sets  is  easily  captured 
by  Ada.  LIR's  mention  the  lack  of  set  notation  for  this  kind 
of  set  and  the  awkwardness  of  the  aggregate  notation. 


The  TEE  Reports  show  an  extremely  favorable  attitude  and  a 
great  daal  of  accaptanca  for  Ada  among  tha  prospective  usars. 
Repeatedly,  Tast  and  Evaluation  participants  mention  tha  advantagas  of 
coding  in  Ada,  maintaining  ays  tarn a  writtan  in  Ada,  transporting  Ada 
programs  to  othar  targat  machinas,  and  so  on. 

Twenty-three  TER's  explicitly  favorad  strong  typing;  tha 
strongast  coamant  on  any  ona  faatura.  Othar  features  with  strong 
appaal  wara  anumaratlon  typas,  ovarloading,  packagas,  tha  separation 
of  spacif lcations  from  bodlas,  rastrictad  visibility,  tasking,  saparata 
compilation,  axcaption  handling,  and  ganerlcs. 

Thara  ara  consistantly  strong  complaints  about  functionality 
only  in  ona  araa:  cask ing  and  intarrupts.  Thara  is  a  graat  deal  of 
concern  that  tha  tasking  and  Interrupt  constructs  cannot  handle  the 
requirements  of  embedded  applications.  Thara  ara  two  sides  to  this 
concern:  one,  semantic  functionality,  tha  othar,  performance 
requirements. 

many  reviewers  indicated  that  they  liked  some  other  language 
better.  Yet,  thara  was  virtually  no  agreement  on  which  language  was 
preferred,  ft  is  clear  from  the  results  that  Ada  is  the  most  viable 
candidate  for  standard! zation  of  any  present  language.  Almost 
everyone  praises  some  faaturas  of  Ada.  Thara  ara  groups  of  people  who 
say  that,  for  example,  PASCAL  if.  just  a  toy,  FORTRAN  is  hopelessly 
backward,  LISP  is  no  good  for  'real*  projects,  etc.  The  reactions  to 
Ada  ara  more  along  tha  lines  of  *tf  only  they  would  change  ona  little 
thing...*.  It  is  expected  that  final  Ada  will  meet  the  very  ambitious 
objectives  of  the  DoO  common  high  order  language  project. 

Another  major  theme  apparent  throughout  the  TEE  analysis  was 
the  need  for  batter  manuals  and  tutorial  materials. 

Thera  is  a  .'ansa  of  optimism  that  the  Issues  which  have  bean 
identified  by  tha  TEE  analysis  can  be  resolved,  and  that  tha  result  of 
the  design  refinement  iirocess  will  be  a  polished  and  effective  tool 
which  fully  meets  the  objective  of  the  Common  High  Order  Language 
Program. 


APPENDIX  A:  TER  Topic  Tndax 

Tha  TER  Topic  Index  cross-references  specific  technical 
concerns  mentioned  in  tha  TER's  with  LRM  chapters. 

Tha  index  basically  serves  two  major  functions:  it  reflects 
a  general  sense  of  tha  technical  opinions  of  tha  Test  and  Evaluation 
participants,  and  it  nay  bring  up  or  emphasize  topics  which  might 
otherwise  not  bo  considered. 
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The  TEH  questionnaire  contains  savaral  saettons  which  ask 
Tast  and  Evaluation  participants  to  list  which  language  features  thay 
liked,  which  thay  thought  ought  to  ba  chanqed,  and  which  thay  thought 
wara  redundant.  Slnca  aany  of  tha  proposed  changes  ware  In  fact 
proposed  additions,  tha  responses  to  these  questionnaire  sections  are 
divided  into  categories  labelled  Add,  Change,  Lika,  and  Redundant. 

Although  this  Topic  Index  certainly  does  not  represent  all 
the  concerns  of  Test  and  Evaluation  participants,  it  represents  those 
issues  which  they  considered  eost  iaportant.  The  questionnaire 
answers  were  put  into  uniform  nomenclature,  and  similar  answers  were 
serged. 

The  Index  entries  were  categorised  by  LRM  chapter  nuaiber 
rather  than  LRM  section  number,  as  most  replies  were  not  specific 
enough  to  ba  related  to  a  particular  section.  After  each  topic  entry 
are  listed  the  TER's  mentioning  it.  Sose  groups  have  submitted  more 
than  one  TER i  some  TER's  are  more  extensive  In  their  coverage  than 
others;  some  TER's  are  more  carefully  considered  than  others;  sons 
topics  are  closely  related  to  others.  For  these  reasons.  It  was 
considered  unwise  to  take  a  count  of  the  number  of  TER's  mentioning  a 
topic.  It  would  be  even  less  wise  to  base  decisions  about  the 
language  on  such  a  count,  since  the  varying  Importance  and  expertise 
of  submitters  of  TER's  are  nowhere  accounted  for. 


1:  A  Language  subsets;  25, 

1:  C  Make  declaration  syntax  more  uniform:  30, 

It  C  Improve  syntax:  4, 

1:  C  Require  blocks  lather  than  sequence  of  statements:  30, 

2:  A  Abbreviations  for  keywords:  3,  30, 

2:  A  Imbedded  cox jents:  30,  72, 

2:  A  Alternate  character  set  support:  13, 

2:  A  Bit  string  constants:  13,  41,  44,  51,  59, 

2:  C  Make  *  *  non-significant:  30,  40, 

2:  L  *  *  In  Identifiers:  19, 

2:  L  Long  Identifiers:  19,  37,  75, 

2:  R  Bases  other  than  2,  8,  10,  and  15:  IB, 

2:  R  Significance  of  "  *  In  tokens:  7, 

3:  A  31 t  handling:  26, ”71,  77, 
i:  A  Function  as  data:  7, 

3:  A  Multi-level  structures:  3, 

3:  A  Implicit  conversion  of  numeric  types  (when  no  loss  of  precision):  30, 
3:  A  Reference  variables:  7,  19,  30, 

3:  A  Simula  classes:  7, 

3:  A  Static  allocation  of  access  objects:  13, 

3:  A  Unsafe  pointers;  14, 

3:  A  Strings:  29,  35,  38,  45,  59,  61,  63,  72, 

3:  A  Variable  declarations  after  local  program  bodies:  84, 

3:  A  Statis  variables:  84, 

3:  C  "»>*  has  two  meanlnqs:  19,  30, 

3;  C  Ranges  should  not  have  to  be  contiguous:  20, 

3:  C  Delta  Is  poor  keyword:  19, 

3:  C  Expressions  lri  range  constraints!?):  8, 
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3:  C  Fixed-point  delta  should  be  exact:  27,  28, 

3:  C  Require  specification  of  maximum  size  of  strings:  2, 

3:  C  Store  Matrices  by  column:  18, 

3:  C  Types  too  restrictive:  IS, 

3:  C  Allow  anonymous  types  in  record  fields:  28, 

3:  C  Use  structure  equivalence  for  arrays:  30, 

3:  C  Guaranteed  one-step  conversion  between  derived  types:  30, 

3:  L  Aggregate  syntax:  7, 

3:  r.  Aggregates:  29,  40, 

3:  L  Arrays:  13, 

3:  L  Enumeration  types:  7,  34,  35,  37,  38,  58,  68,  75,  88, 

3:  L  Derived  types:  88, 

3:  l  Machine- Independent  data  definition:  2, 

3:  L  Overloading:  2,  7,  35,  37,  42,  61, 

3:  L  Precision  specification:  13, 

3:  L  Record  syntax:  19, 

3:  L  Record  variant  seeantics:  29, 

3:  L  Initialization  in  declarations:  86, 

3:  L  Strong  typing:  2.  3,  10,  IS,  18,  26,  29,  31,  46,  48,  50,  52.  54,  58, 
3:  l  variant  arrays  in  records:  86, 

3:  L  Arrays  with  unspecified  index  range:  86, 

3:  L  Type  constraints:  1,  20,  49, 

3:  L  user-defined  types:  S,  17,  26, 

3:  L  Scope  for  access  types:  29, 

3:  R  Subtypes:  87, 

3:  R  Either  subtypes  or  derived  types:  19, 

3:  R  Derived  types:  29, 

3:  R  Naned  coeponents  in  aggregates:  25, 

4:  A  Conditional  expressions:  7,  28,  30, 

4:  A  Multiple  assignments:  30, 

4:  A  Method  of  expressing  parallellsat  in  expression  evaluation:  21, 

4:  A  'Free'  operation:  29,  *9, 

4:  A  Standard  bullt-lr,  eath  library:  19, 

4:  A  Standard  built-in  array  operations:  16,  19, 

4:  C  Accurate  fixed  point  arithmetic  (specification,  coercion) :  8,  85,  88 
4:  C  Define  mathematical  properties  of  user-defined  operators:  1, 

4:  C  More  control  over  allocation:  13,  15, 

4:  C  Quail?* «d  expression  syntax:  13, 

4:  C  Time  should  not  be  floating  point:  19,  86, 

4:  C  User  type  names  should  be  overloadable  as  conversion  functions:  83, 
4:  L  Attributes:  20,  2i,  29, 

4:  L  Expression  structure:  19, 

4:  L  Array  slicing:  29,  88, 

4:  L  No  automatic  type  conversion:  14, 

4;  R  Allocators  for  access  types:  1, 

4:  R  Array  slicing:  18, 

5:  A  Combined  For  and  While  statements:  16, 

5:  A  Compound  statements:  7, 

5:  A  loop  failure  exits:  17, 

5:  A  More  loop  constructs:  13,  16,  27,  87 
5:  A  Block  exits:  83, 

5:  A  Exit  from  named  block:  30, 

5:  C  Remove  mandatory  semicolon  before  end,  elrif,  etc.:  30, 

5:  C  Allow  mixing  of  "and  then*  and  *or  else*:  28, 
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5:  C  Us*  "do*  not  "loop*  as  keyword:  19, 

5:  C  Allow  VHP's  as  conditions:  38, 

5:  C  Overloading  rules  too  complicated  w.r.t.  parameters:  86, 

5:  L  Recursion:  28,  21,  22, 

5:  L  Stiuctured  programming  constructs:  2,  S,  18,  13, 

5:  R  El  si f :  18,  19, 

5:  R  Exit  when:  8,  54,  85, 

5:  R  Exit:  4, 

5:  R  Function  call  syntax:  28,  86, 

5:  R  Keyword  parameter-association  syntax  (:»:,  etc.):  7,  19,  27, 

5:  R  Assert:  38,  54,  64, 

5:  R  Labels  and  gotos:  1,  4,  38,  84, 

5:  R  Short  circuit  conditions:  18,  54,  88, 

5:  R  VHP's:  29, 

6:  A  Functional  arguments:  8,  28,  21,  28,  48,  74,  85, 

6:  A  Intermixed  declarations:  7, 

6:  a  Generalize  ini ti al i zat ion  in  type  declarations:  38, 

4:  A  Not  recursive/reentrant  declaration:  2, 

6:  A  Variable  nurber  of  parameters:  29, 

4:  A  Guaranteed  'jy-value  calls:  84, 

6:  C  Define  parameter  passing:  18, 

6:  C  Reference  passing  preferred:  14, 

4:  c  Functionality  should  not  be  compiler-verified:  86, 

6:  L  Initialization  in  declarations:  29, 

6:  L  Default  parameters:  7,  29,  35, 

4:  L  Functions  and  VHP's:  21,  22, 

4:  L  Parameter  modes:  86, 

4:  R  Declarations  in  blocks:  7, 

6:  R  Default  parameters:  25, 

6:  R  Initial  values  in  decl -rations:  25, 

6:  R  Optlonallty  of  block  declarations:  1, 

4:  R  Recursion  support:  13, 

4:  R  Tasks  and  Procedures  should  be  merged:  5, 

4:  R  VRP's:  26, 

7:  C  Allow  representations  in  private  part:  28, 

7:  L  Information  hiding/data  abstraction  in  general:  18,  14,  28,  34, 

7:  L  Packages:  4,  8,  18,  16,  29,  48,  46,  58,  52,  56,  58,  61,  68,  73, 

7:  L  Private  types,  parts:  2,  8, 

7:  L  Separate  specifications:  1,  2,  13,  19,  38,  47,  58,  58,  69, 

7:  R  Nested  packages:  IS, 

7:  R  Scoping  hierarchy:  13, 

7:  R  Separate  specifications:  18, 

8:  C  Clarification  of  separate  compilation  and  visibility:  1, 

8:  C  Loop  index  should  be  valid  beyond  end  of  loop:  27, 

8:  C  Restricted  is  poor  keyword:  19, 

8:  C  Visibility  rules  disliked:  13,  46,  49, 

8:  L  Logical  scop*  rules:  16,  18, 

8:  L  Restricted  visibility:  4,  22,  23,  55,  87, 

8:  L  Private  types:  87, 

8:  R  Us*  clause:  25, 

9:  A  Background  tasks:  13, 

9:  A  Initiate  perameters:  11, 

9:  A  Mutual  exclusion  to  data  access:  22,  23, 

9:  A  Timed-out  entry  calls:  38,  86,  87, 


9:  A 
9:  A 
9: 

3:  C 
9s  C 
9:  C 
9:  C 
9s  C 
9s  C 
9s  L 
9s  L 
9s  L 
9s  R 
9s  R 
10s  C 
10s  C 
10:  C 
10s  L 
10:  l 
11:  L 
Us  C 
12:  A 
12:  A 
12:  C 
12:  t. 
12:  R 
13:  A 
13s  A 
13:  A 
13:  A 
13:  A 
13:  C 
13:  C 
13:  C 
13:  L 
13:  L 
13:  L 
13:  L 
14:  A 
14:  A 
14:  A 
14:  A 
14:  C 
14:  C 
14:  C 
14;  C 
14:  L 
14:  R 
Z  :  C 
Z  s  L 


Suspend  and  resume  of  tasks:  82, 

Easier  cyclic  scheduling:  88, 

Disallow  data  shared  between  tasks:  20,  21, 

Forbid  aborting  or  changing  priority  of  parent  tasks:  8,  85, 
Interrupt  semantics:  13,  25,  82, 

More  control  over  scheduling:  13,  26.  82, 

Preemptive  priorities:  27, 

Rendezvous  too  restrictive:  15, 

Static  priority:  1, 

Tasking:  4,  10,  20,  21.  27,  29,  33,  71,  75,  77,  83,  85,  36,  88, 

Task  families:  88, 

Rendezvous  arguments:  29,  38, 

Tasking  too  comp.ex:  15, 

Signals  and  seaaphores:  30, 

Allowing  deferred  constants  to  be  set  in  a  separate  compilation  unit 
Have  different  visibility  rules  for  separate  compilation:  30, 
Separate  units  should  have  full  upward  visibility:  87, 

Prograa  structure:  16, 

Separate  compilation:  10,  19,  26,  54,  68,  72,  73,  87 
Exception  handling:  7,  18,  20,  29,  33,  38,  58,  86, 

Exceptions  in  declarative  parts  should  propagate  up:  86, 

Type  restrictions  for  generic  paraaetars:  8,  85, 

Coaponent  naaes  as  generic  parameters:  29, 

Generics:  20, 

Generics:  2,  18,  38,  58,  68,  86,  87,  88, 

Generics:  3,  69, 

Overlays:  1,  26, 

Representation  of  integers  as  bit  fields:  16, 

Records  with  overlapping  fields:  29, 

Representation  specification  of  fixed  point  binary  point:  18,  19, 
Better  Fortran  interface:  87, 

Improve  alignment  specifications:  13, 

Machine  code  Inserts  clumsy:  15,  41,  47, 

Incorporate  representations  into  type  definitions:  27, 

Record  representation:  19,  38,  44, 

Representation  specifications:  19,  27,  56,  88, 

Machine-code  insertions:  27, 

Unsafe  conversion:  88, 

Timeout  on  I/O:  11,' 

Fortran-like  Formats:  0, 

Mixed-node  files:  82, 

A  high-level  real-time  I/O  mechanism:  82, 

EOF  not  exception:  14,  62, 

I/O  Incomplete:  13, 

Operating  system  assumed  too  big:  13, 

Extend  Text_IO:  0, 

I/O  as  package:  1,  7, 

Send_control ,  Rece 1 ve_control  {in  Low_level_IO) :  1, 

Keywords  are  overloaded;  87,  ~  ~ 

Matching  keywords  (e.g.  if  —  endif):  87, 
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APPENDIX  Bi  Issues  flit 

Ju st  as  the  Topics  Index  cross  rsfarancss  TER  issue',  wl  ;h  Che 
Ada  Language  Reference  Manual,  the  Issues  file  cross  references 
concern  found  In  the  LIR's  with  the  LRM. 

The  Issues  file  is  organized  bv  section  number  cf  the 
Preliminary  Ada  LRM.  under  each  section  n us her  are  grouped  abstracts 
of  cosaents  relating  to  that  section.  The  coaaents  are  nuabered  by 
section  nuaber  with  a  serial  letter  following.  Thus,  "2. 3. A*  1s  the 
first  coaaent  on  section  2.3. 

The  relation  of  coaaents  to  sections  is  at  best  approsiaate, 
since  many  issues  cross  section  boundaries.  In  order,  therefore,  to 
sake  the  document  more  useful,  cross-references  to  other  sections  are 
entered  under  coaaents.  Text  processing  tools  can  extract  these 
cross-references  and  place  them  under  the  sections  cross-referenced. 

The  content  of  an  issue  abstract  is  intended  to  reflect  the 
intent  of  the  coaaent  writer;  no  evaluation  of  its  substance  is 
intended.  Several  coaaents  which  aake  the  saae  general  point  are 
indexed  under  one  issue  abstract;  they  aay  nonetheless  differ  in 
detail.  Although  the  abstracts  are  Intended  to  be  informative  and 
useful  apart  from  the  coaaents,  in  general  It  is  necessary  to  read  the 
comment  itself  in  order  to  understand  the  analysis,  justifications, 
and  suggestions  contained  in  it. 

The  abstracts  are  generally  self-explanatory.  In  order  to 
keep  them  concise,  they  are  often  presented  as  statesents  of  fact  even 
though  the  point  may  be  debatable  (e.g.  ‘tasking  is  Inflexible*). 
Syntactic  terms  and  reserved  words  are  capitalized  1  (e.g. 
Exponentlating_operator,  Begin).  ‘Presumably*  means  that  the  comment 
writer  felt  the  manual  was  lncosiplete  (e.g.  ‘labels  are  presumably  In 
a  different  name  space*).  An  absolute  statement  such  as  "Ada  forbids 
subscripting  of  functional  values*  may  safely  be  taken  that  the  author 
of  the  comment  felt  this  construct  should  not  be  forbidden.  An 
indication  of  •(?)*  after  an  abstract  indicates  that  the  abstractor 
feels  that  he  may  not  have  fully  understooi  the  Intent  of  the  comment. 


Internal  format 

The  file  is  organized  in  such  a  way  as  to  make  automatic 
processing  relatively  easy.  When  formatted  versions  of  the  issues 
file  are  produced,  a  copy  is  put  in  <TNE-Archive>  under  the  name 
Issues. Formatted.  In  order  to  allow  for  the  variety  of  output 
devices,  the  ’formatted*  file  is  not  paginated,  since  the  LIR  log  is 
annotated  with  references  to  the  Issues  file,  it  Is  possible  to  see 
where  a  particular  LIR  has  been  entered  and  cross-referenced. 

There  are  three  kinds  of  entries:  section  names,  abstracts, 
and  references.  Section  name  entries  are  of  the  form: 
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*$*  (section  number)  (section  name). 

Each  section  of  the  LRH  ia  represented  by  Its  saction  name  as  found  in 
tha  tabla  of  contents,  avan  if  no  abstracts  ara  found  undar  it. 
Abstracts  of  comments  ara  of  tha  form: 

*%*  <sactlon  number> .< comment  serial  letter) 

<connent  abstract)  <cross-ref erences) 

Comment  serial  letters  run  A-Z  than  ZA-ZZ.  Cross-references  are  of 
the  form: 

•XX*  (section  number)*  *. 

References  to  other  documents  are  of  tha  form  "(references)*, 
where  the  references  are  document  numbers  separated  by  commas.  In 
certain  categories  of  documents  (notably  P2Rs) ,  section  or  page 
numbers  within  the  document  are  given  in  parentheses  after  the 
document  numbers:  these  page  numbers  are  usually  stripped  off  before 
further  processing  of  references. 

A  representative  fragment  of  tha  internal  form  of  the  Issues 
file  follows: 

$  6.7  Blocks 

t  6. 7. A  It  should  be  possible  to  name  all  blocks,  perhaps  uniformly 
with  loops.  XX5.6! 

1  LIR.066,  LIR.222 

(end  of  abstract) 

The  formatted  Issues  file  contains  exactly  the  same 
information,  but  is  formatted  for  human  readability.  The  processed 
LIR  log  found  in  another  section  of  this  report  contains 
back-references  from  LIR's  to  issue  entries. 


1. _ INTRODUCTION 


1.1  Design  Goals 

1.1. A  The  language  addresses  too  many  conceptual  levels:  pragmas  and 
separate  compilation,  for  example,  are  support  system  functions.  XX2.7 
XX10.0 
LIR. 584 

1.2  Language  Summary 

1.3  Sources 

1.4  Syntax  Notation 


I 


22 


1.4. A  Clarify  the  meaning  of  brackets. 

LIB. 489 

1.4.8  The  syntax  rules  should  b«  numbered  for  assy,  unambiguous  reference 
LIB. 405 


1.4.C  Nonterminals  should  ba  capitalized.  This  helps  distinguish  syntact 
Name  from  the  concept  of  'name*. 

LIB. 637 

1.4.0  Some  becter  metasyntax  for  one  or  more  repetitions  (with  separators 
should  be  used,  eg  "Name  list  ,"  or  "Name  ,  ..."  for  present  "Name  {,  Name} 
LIB. 637 

1.4. C  Observing  the  grammatical  distinction  between  "which*  (descriptive) 
and  "that*  (restrictive)  would  clarify  manual  explanations. 

LIB. 438 

1.5  Documentation 


2.  LEXICAL  ELEMENTS 


2. 9. A  There  should  be  a  complete  lexical  grammar,  separate  and  distinct  f 
the  phrase  structure  grammar,  In  the  LBN. 

LIR.639 

2. 1  Character  Set 


2.1.  A  Commas  are  preferred  to  vertical  bars  in  the  syntax.  XX3.6.2  XX3.7 

XX5.5  XX11.2 

LIB. 308 

2.1. C  The  Ada  character  set  uses  characters  reserved  for  national  use 

according  to  ISO  646.  "I"  In  particular  should  be  removed. 

LIR.394 

2.2  Lexical  Units  and  spacing  Conventions 

2. 2.  A  The  symbol  •■>•  should  be  replaced  by  In  aggregates  and  "then" 

in  case-1  Ike  statements.  XX3.6.2  XX3.7.2  XX5.5  XX9.7  XXU.2 

LIR.205  LIR.313 

2.3  Identifiers 


2. 3. A  Underscores  should  be  allowed  but  not  be  significant. 
LIR.346 


2.3.B  Tor  compatibility  with  other  naming  conventions  fGCCS,  CP-6 
Nultics),  *$*  should  be  a  letter  and  terminal  *  *  should  be  allowed. 
LIR.482 
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2.4  numbers 

2. 4.  A  Real  numbe.'  literals  should  not  require  a  decimal  point  or  trkllinc 
or  leadinq  zero. 

LXR.040  LIR.425 

2.4. B  A  number’s  form  should  not  affect  its  type:  *23*  should  be  a  legal 

floating  number,  and  "1.2ES*  a  legal  integer. 

UR.  148 

2.4. C  There  is  no  way  to  write  a  Boolean-array  constant  (bitstring)  as  a 

numeric  literal. 

UR.24S  LIR.24S 

2.4.0  Based  integers  need  not  he  built  in.  Muard(*16l2A“)  suffices. 

UR.  294 

2.4. E  *  *  for  spacing  should  be  permitted  anywhere  within  a  number. 

UR.  320 

2.5  Character  Strings 

2.5.  A  The  Interchangeability  of  *  and  t  as  string  delimiters  causes 
unnecessary  confusion. 

UR.  084  LIP.  104  UR.  217  LIR.493 

2.5. B  There  should  be  a  distinct  convention  for  character  literals,  eg 

'a',  Sa,  la,  rather  than  allowing  the  length-one  string  to  stand  for  them. 
XX4.4 

LIR.297 


2.5. C  The  character  •'’•*  does  not  distinguish  opening  and  closing  and  is 

not  Steelman  approved.  <<.. .string. . .>>  is  suggested.  XX2.1 

LIR.314 

2.5.0  What  is  the  syntax  of  character  literal?  XX3.5.1 
UR. 499 

2  ,f>  Comments 

2. 6.  A  Embedded  comments  desired. 

LIR.345  LIR.402  LIR.580 

2.6. B  Comments  should  appear  at  the  beginning  of  lines,  terminated  by  *— 

LIR.193 

2.7  Pragmas 

2. 7.  A  Pragmas  that  alter  the  semantics  of  programs  should  be  deleted  or 

incorporated  as  language  features,  eg  Environment,  Include.  XX8.6  XXB 
EVR . 001 (pis)  EVR. 002(1215)  P2R. 022(107)  LIR.069  LIR.160 

LIR.532 
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2.7. B  Redundant  pragmas  should  ba  delated.  Pragmas  which  never 

influence  compilation  should  not  be  addressed  in  the  LRM. 

EVR .002(1302)  P2R.022 (405) 

2.7. C  There  should  be  soma  indication  of  the  compulsory  strength  of  a 

pragma.  The  programmer  should  be  notified  whenever  a  pragma  is  not  acted 
upon  by  the  compiler. 

EVR . 001 (plS)  EVR. 065(13.8) 

2.7.0  There  should  ba  a  conditional  compilation  pragma. 

LIR.03** 

2.7. E  There  should  be  a  pragma  requiring  compile-time  initialisation. 

LIR. 249 

2.7. F  Pragmas  should  have  well-defined  scopes  and  syntactic  positions. 

LIR. 292 

2.7. G  There  should  be  a  sliding  scale  of  space  vs.  time  optimization. 

LIR. 300 

2.7. H  Pragmas  should  be  part  of  the  support  system,  not  the  language. 

LIR.584 

2.7.1  Pragmas  should  be  allowed  static  expressions  or  at  least  names  as 
parameters. 

LIR.  <528 

2.7. J  The  Environment  and  Suppress  pragmas  have  'name*  parameters,  despit 

the  syntax  definition.  XX8.fi  XXll.fi 

LIR. 217 

2.8  Reserved  Words 

2. 8.  A  The  word  'delta*  should  not  be  reserved:  it  is  too  common  a 
variable  name.  XX3.5.5 

LIR. 401 


3.  DEC LA RATI QMS  AND  TYPES 


3.0. A  Explicit  type  parameters  should  be  permitted  for  any  user-defined  t 
arrays  should  not  be  a  special  case.  Type  parameters  should  be  bound  for 
individual  variables  of  the  type  at  the  point  of  their  allocation  {e.g.  at 
point  of  declaration  for  non-access  types). 

EVR. 002(4103)  P2R .01 3 ( #02)  P2R. 018(401)  P2R. 027(405)  P2R. 027(406) 

P2R . 038 ( 40fi)  P2R. 039(405)  P2R. 046(403)  LIR. 142 

3.0.8  Name  equivalence  should  apply  to  types. 

P2R. 012(403) 


PL/I-llk*  based  variables  ara  dust  red 


3. 0.C 
LIB. 129 


3.9.0  Tb*  concept  of  •elaboration*  la  not  fully  and  claarly  daflnad. 
XX7. 0  XX9. f 

LIB. 143  LIB.32S 

3.«.e  Types  should  hav*  attributes  such  as  'la. Scalar  for  ua*  in 
restrictive  asaartlona  in  generics.  XX12.0  XXA 
LIB. 258 


3.0.F  Pull  functional  values  ar*  daairad:  variables  ahould  b*  allowed  to 
hav*  functions  aa  values;  functional  arguments  and  values  should  be  allowed 
Son*  errors  will  be  undetectable  by  the  compiler,  but  Integration  into  the 
language  is  safer  than  laachin*  insertions. 

LIB. 335  LIB. 389  LIB. 596 

3.0.G  Parameters  of  types  should  be  explicit;  there  should  be  a  defaultlr 
mechanism  for  them. 

LIB. 142 

3.1  Declarations 


3.1.  A  Ada,  like  Pascal,  requires  declaration  before  us*.  This  is 
a  semantically  empty  restriction  on  program  structure. 

P2B. 013 ( #65) 

3.1. B  Declarations  should  start  with  a  keyword.  This  makes  parsing  and 

reading  easier. 

LIB. 630 

3.2  Object  Declarations 

3. 2.  A  Thar*  should  some  way  to  force  static  allocation  of  local 
variables.  XX13.0 

LIB. 326 


3.2.B  If  No  Valu*_Brror  is  to  be  removed,  all  objects  should  be  required 
to  be  initialized  explicitly  or  implicitly,  eg.  Integers  to  Maxlnt,  access 
objects  to  Null. 

LIB. 426 


3.2.C  The  semantics  of  constants  should  more  completely  specified  (cf. 
private  types,  constant  record  components).  XX3.7.1 
LIB. 485 


3.2.D  The  right  hand  side  of  object_initlalizatlon  should  allow  an 
expression  list. 

LIB. 605 


3.2.E 
LIB. 137 


Constants  set  at  load  time  ar*  needed 


3.3  Typo  and  Subtype  Declarations 

3.3. A  S49  3. A. A. 

P2R . f 39 ( #23) 

3.3. B  The  Ada  sec  type  ia  adequate  for  bit  string  operations,  but  la  not 

an  aeeaptabla  aubatituta  for  sets.  Trua  Paacal-lika  aata  would  ba  a  valuat 
aid  to  raadabllity  and  eoncaptual  clarity  in  complex  flow-of -control  probl* 
EVR.005(  113.0  P2R. 002(401)  LIR.05R 

3.3. C  For  implementation  of  library  packages,  a  mechanism  to  dafaat  atror 

typing  ahould  ba  provldad.  Thla  could  ba  providad  by  the  “any*  typa. 

P2R. 036(413) 

3.3. D  tt  should  ba  possible  to  daflna  initialisation  and  finalisation 

routinaa  for  eypaa. 

EVR .0(3(13.3)  P2R. 046 ( #82) 

3.3. E  Constraints  do  not  appaar  to  ba  tha  distinguishing  faatura  of 

subtypas.  Thara  la  soaa  confusion  in  tha  dafinitlon.  Constraints  should  1 
raforaulatad  so  that  typas  can  ganuinaly  ba  composed.  Without  this,  tha 
important  notions  of  modularity  A  la  Parnaa  ara  difficult  to  express. 

EVR. (*03(43.1)  P2R. 013(401)  P2R. 039(406) 

3.3. P  Inconplata  typa  daclaratlona  ara  unnacaasary  sinca  tha  ldantlflars 
thus  daclarad  must  naads  ba  typas  in  tha  contacts  whara  thay  ara  usad. 

LIR. 054 

3.3.  C  Typa  daclaratlona  should  ba  abla  to  provide  dafault  initial  valuas 
for  all  typas. 

LIR. 144  LIR. 355  LIR. 497 

3.3. H  It  aaaaa  that  "type  t  is  ranga  0..10*  defines  t  as  a  subtypa  of  an 

anonymous  baaa  typo.  What  ia  that  typa?  What  arlthaotlc  is  usad  for  t  anc 
lntaraadlata  axprasalons  of  typa  t  axpraaslona?  XX3.5.4 

LIR. 246 


3.3.1  Subtypaa  should  ba  alialnatad  as  dafaatlng  strong  typing,  in  favor 
of  darlvad  typas  alona. 

LIR. 312 

3.3.J  Convaniant  and  intultiva  syntax  for  sets  (arrays  of  booleana) 
would  ba  vary  holpful.  Pascal  sats  likad. 

LIR. 400 


3.3.K  Ara  inconplata  typo  declarations  rastrictsd  to  mutually  dependent 
access  typas?  What  can  you  do  with  than? 

LIR. 495 


3.3.L  It  should  ba  made  perfectly  clear  that  a  subtypa  la  compatible  with 
its  parent. 

LIR. 496 


3.3. M  Subtypes  are  types  with  the  sat  of  values  restricted.  It  should 

also  ba  poasibla  to  rastrict  tha  attributes.  XX7.4 

LIR.561 

3.3. N  Tha  dlffaranca  between  ‘type  T1  Is  new  Integer*  and  ‘subtype  T2  is 

Integer*  appaars  to  ba  only  that  in  cartaln  positions  T1  objacts  oust  ba 
axpllcitly  convartad.  Doas  this  slight  dlffaranca  justify  having  both 
concepts? 

LIR.S05 

3.3.0  Subtypas  should  navar  ba  lsplictly  introducad  via  typa  derivation  « 
XX3.4 
LIR.61S 


3.3.P  Name  aguivalanea  of  array  typas  forcas  a  prollfaratlon  of  typa  name 
Array  typas  should  ba  subject  to  structural  aguivalanea.  Typa  spacificatlc 
should  ba  allowad  as  wall  as  typa  names  for  formal  paraaatars.  XX3.S  XX4.6 
IIR. 221 

3.4  Darlvad  Typa  Daflnltlons 


3. 4. A  Tha  facility  for  iaplicit  definition  by  inheritance  of  operations  f 
underlying  typas  using  tha  ‘new*  type  declaration  should  ba  flexible  enough 
allow  (encourage)  alternative  definitions  of  individual  operations  whan  the 
default  Is  Inappropriate.  XX7.4 
EVR.002(I20«)  P2R. 027  ( 187) 


3.4.8  After  tha  declaration  ‘Peat  is  naw  integer*,  tha  languag 
automatically  derives  an  unwantad  operation  that  multiplies  twolv 
Peat,  returning  a  value  of  typa  Peat. 

P2R. 013(103) 


values  of  t 


3.4. C  Derived  typas  should  inherit  constants  froa  their  ancestral  type. 

C.IR.  029 

3.4. D  Deriving  from  a  private  typa  should  presumably  ba  forbidden.  XX7.4 

LIR.486 

3.4. E  Subprograms  declared  after  derivation  are  presumably  not  inherited. 

C.IR.498 


3.4.P  Doas  a  typa  derived  from  an  access  type  share  tha  parent's 

collection?  Doas  it  inherit  tha  length  specification?  what  attributas  doc 

it  inherit?  XX3.8  XX13.2 

LIR.SR2 


3.4.0  Inheritance  of  operations  by  derived  typas  leads  to  much  confusion. 
Automatic  inheritance  by  conversion  is  superior.  Inter  alia,  it  allows  for 
mixing  of  types  and  derived  typas  as  appropriate. 

LIR.284 


3.3  Scalar  Typas 
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3.5. A  See  3.5.5.G. 

LIR.X13 

3. 5.8  'Ord  and  'Val  «ra  subject  to  pathologies  and  are  not  fully  daflnad. 
LIR .116  LIR. 8*3 

3.5. C  Thara  should  ba  a  'Rang*  attribute:  A 'Range  »«  A’ first. .A'Last,  or 

perhaps  a  type  name  should  ba  able  In  general  to  stand  for  T'Range.  XX3.6 
XX3.3 

LIR.  827  LIR.  158  LIR.  223  LIR. 235  UR.836 


3.5.0  Pred  and  Succ  should  ba  overloaded  functions  rather  than  functional 
attributes  of  types. 

LIR. 155 


3.5. B  'Pred,  ’Succ,  'Ord,  and  'Rep  (and,  aventuelleaent,  ’Range)  should  t 

allowed  for  objects  as  well  as  types.  This  would  sake  anonyaous  types  more 
useful .  XXA 

LIR. 223  LIR. 428 

3.5. P  What  are  'First  and  'Last  of  enpty  ranges?  and  'Ord  'first? 

LIR. 228 

3. 5. G  There  is  no  way  to  write  an  espty  range  of  a  type  with  just  one  val 
LIR. 228 

3.5.1  Enumeration  Types 

3. 5.1.  A  The  extent  to  which  overloaded  literals'  aeanlng  Is  determined  by 
contextual  information  is  left  unclear. 

LIR. 874 

3.5.1. B  Are  a  and  ‘a*  equal  enuserals?  What  is  the  I/O  fona?  XX14.3.7 

LIR. 382 


3.5. l.C  Unordered  enumerated  types  are  desired,  why  should,  eg,  colors  be 
ordered?  Of  course,  this  would  require  the  facility  of  using  type  names  tc 
represent  the  whole  collection  of  objects  of  the  type.  XX3.6 
LIP.  888 

3.5.2  Character  Types 

3.5.3  Boolean  Type 

3.5.4  Integer  Types 

3. 5. 4. A  The  type  'Integer*  introduces  unfortunate  sachlne  dependency. 

LIR. 091  LIR. 154 

3. 5. 4.8  Integers  should  be  pure  ranges  (not  derived  frosi  Integer). 

LIR. 383 


-  29 


3.S.4.C  Integer  types  are  derived  f roe  one  of  Short  Integer,  etc.:  can  a 
Short_lnteger  value  be  added  by  standard  to  an  Tnteger  value?  If  yes 
say  so;  If  no,  portability  suffers.  XX4.5  XX6.6 
UR. 500 


3.5. 4.0  Can  Short  Integers  be  assigned  (converted?)  to  Integers? 
UR. 501 


3.5.4. E  Unsigned  Integers  desired.  XX13.0 

UR. 613 

3.S.5  Real  Types 

3. 5. 5.  A  The  implemented  fixed  point  delta  should  be  an  Integral  divisor  of 
the  specified  delta.  The  fixed  point  range  specification  should  constrain 
rather  than  determine  the  Implemented  representation. 

EVR. 002 ( 4202)  P2R. 025(493)  P2R. 028(403)  »2R. 039(401)  P2R. 044(401) 

P2R. 044(402)  UR. 585 

3.5.5. B  Fixed  point  literals  and  values  shuulu  be  rounded  Implicitly. 

EVR. 002(4202) 

3.5.5. C  It  should  be  possible  to  specify  the  range  of  exponents. 

EVR. 005(42. 2)  P2R. 039(402) 

3.5.5. D  A  semantic  model  of  Ada  numerics  is  needed. 

UR. 020 


3.5.5. E  The  delta-type  accuracy  constraint  syntax  incorrectly  specifies 

range  constraint  as  optional. 

UR.  135  UR.  270  UR.  403  UR.  605 

3.5.5. P  Fixed-point  arithmetic  should  support  general  scaling. 

UR.  232 

3.5.5. C  Range  constraints  are  simultaneously  too  vague  in  specifying 

endpoints  (open  vs.  closed  Intervals)  and  too  restrictive  in  requiring 
exact  endpoints  (hampering  development  of  efficient  machine  Independent  coc 
UR. 113 


3.5.5. H  Ranges  should  be  closed,  not  open. 

UR. 316 

3. 6. 5. I  Floating  precision  should  be  specified  not  by  digits,  but  by  relat: 
delta,  which  is  more  accurate  and  more  useful. 

UR.  330 

3.5.5. J  Define  the  terms  'floating  point  type'  and  'fixed  point  type". 

UR.  502 

3.5.5. K  Are  T’Small  etc.  defined  by  the  range  and  accuracy  constraints 

(one  or  both?)  alone  or  also  by  the  implementation? 

UR. 503 


3.5.5. L  What  arc  T'Saall  and  T'Large  for  Clxad  types? 

LIR. 504 

3.5.5. H  Do  not  eoaplicata  ranqes  with  opan  va.  eloaad  ate. 

LIR. 208 

3.6  Array  Typas 

3. 6.  A  Tha  diatlnction  batwaan  type  mark  and  discrete  range  specification 
of  array  bounda  makes  for  unnecessarily  complex  rulaa:  array(T)  should  ba 
equivalent  to  arrayfT  Ranga  T* PI  rat. .T' Last) .  This  would  also  ba  a  aora 
convaniant  notation  In  aany  casas.  XX3.5 

P2R . 039 (123)  LIR.152  LIR. 476  LIR.593  LIR.612 

3.6. B  Raggad  arrays  ara  daslrad. 

LIR. 336 

3.6. C  Arrays  should  ba  stored  by  rows. 

LIR.370 


3.6. D  Tha  syntax  and  saaanrics  of  aultlpla-indax  arrays  should  be  clarlfl 

Is  array(a,b)  antirely  aquivalant  to  array(a)  of  array(b)?  In  particular, 
is  the  typa  of  subarrays?  Can  tha  notation  A(x,y)  be  used  for  arrays  of 
arrays?  Can  catenation  be  applied  to  nultidimenslonal  arrays  interpreted  a 
(one-dimensional)  arrays  of  arrays?  Is  'Langth(2)  meaningful  for  arrays  of 
arrays?  why  must  all  or  no  index  positions  ba  specified  by  discrete  ranges 
XX4 • 1  XX4 .5.3 

LIr! 487  "  ’  LIR.506  LIR.513  LIR. 567  HR. 615 

3.6. E  Tha  integer  i  in  'Pirst(i)  should  be  required  to  ba  static  (if  it 

is  not,  what  exception  does  a  bad  value  raise?):  the  rare  dynamic  case  can 
ba  handled  with  a  Casa  statement. 

LIR. 505 


3.6.P  If  T1  is  an  array  of  T3's,  how  do  we  declare  a  subtype  of  T1  with 
index  constraints  on  T3  (another  array  type)?  Extensive  discussion. 
Discussion  of  the  interaction  of  arrays  of  arrays  and  private  types. 
Components  of  a  structured  typa  must  be  subtypes:  a  clear  set  of  rules  for 
coercion  from  a  type  to  a  subtype  must  ba  given.  Forbid  subtypes  of  subtyp 
Let  the  nonterminal  type_mark  denote  a  subtype:  define  coercion  rules  for  1 
Disallow  index  ranges  In- an  array_type_def Inition.  Give  the  unconstrained 
integers  and  reals  type  names.  ~ 

LIR. 615 

3.6.1  Index  Range  of  Arrays 

3.6.1. A  Arrays  should  be  one-origin  by  default. 

LIR. 043 
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3.8. 1. B  The  rule  on  index  ranges  of  array*  In  records  seems  to  exclude 
constant-length  array*  within  record*  with  Index  range  determined  by 
external  nonconstants,  eg.  Record  S:  Array(l..x)  End,  where  x  la  a  variable 
(not  a  record  field).  Bound*  determinable  at  type  declaration  elaboration 
should  be  allowed. 

LIR.508 

3.6.2  Aggregate* 

3. 6. 2.  A  Having  to  specify  values  for  all  components  of  an  aggregate  Is 
both  awkward  and  Inefficient. 

LIR. 008  (s3. 3)  P2R. 046(101)  UR. 163  UR. 361 

3.6. 2.  B  Mixed  array  aggregate*  with  array  bounds  which  are  not  static 
result  In  unnecessary  run  time  Inefficiencies. 

OPA.013 

3. 6. 2.0  Initializing  multidimensional  non-constant  aggregates  is 
painful  in  the  current  syntax. 

UR.  134 


3.6. 2.  E  Component  association  syntax  should  use  rather  than  *■>* 

for  consistency.  XX2.2 

UR .  1 35  UR.  313 

3.6. 2.  P  The  use  of  simple  parentheses  to  denote  aggregates  Is  hard  on  the 
parser  and  strains  the  type  disambiguation  mechanism.  XX4.6 

UR .  999 


3.6. 2.  G  Is  5  I  Others  a  legal  component  association? 

LIR.509 

3.6.2. H  The  syntax  of  Choice  should  Indicate  that  th*  expressions  on  th* 

right  hand  side  must  be  static  (Italicized  prefix  Static). 

UR.  60S 

3. 6. 2. I  Th*  us*  of  *1*  is  corfusing.  A  preferred  syntax  for  aggregates 
would  be,  eg,  (1,3,1)  for  positional,  and  ( (1, 3)»>1, (2)»>3)  for  named 
component  selection. 

UR.  205 

3.6.2. J  Hull  aggregates  require  a  superfluous  value:  ( 1 .  ,0'*>dummy)  . 

UR .  220 

3.6,3  Strings 

3. 6. 3.  A  Maximum  string  length  should  be  an  independent  syrtem  attribute 
not  Integer* Last. 

LIR.117 


3.6.3.B  Strings  should  be  of  fixed  size  but  variable  length  or 
heap-allocated. 

LIR.126  LIR.085 
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3.4. 3.  C  Ada  'Strings'  ara  not  the  same  baast  as  strings  in  othar  languages 
Batter  strings  (variable  length)  are  needed:  perhaps  access  type  with 
special  lexical/syntactlc  fora. 

LIR. 177  LIR. 265  LIR. 365  LIR. 404  UR. 456 

3.6. 3.  D  Beeter  strings  are  wanted:  in  particular,  strings  of  different 
(physical)  length  should  be  type-eospatlble. 

LIR. 386 


3.6. 3. E  Null  strings  should  be  permitted.  XXC 
UR. 456 

3.7  Record  Types 

3. 7.  a  The  rules  for  allowable  (dynamic)  dependencies  sawing  record 
components  are  too  restrictive. 

UR. 608  (s2. 1 ) 

3.7. B  Distinction  between  discriminants  constrained  statically  (at 

declaration)  vs.  dynamically  (on  ini t i al 1 zat ton  or  assignment)  causes 
confusion. 

LIR . 008 (s2 . 2) 

3.7. C  Current  semantics  of  record  discriminants  Interfere  with  efficient 

implementation  of  parameter  passing. 

LIR. 008 (S3. 3) 

3.7.  D  It  should  not  be  possible  to  assign  the  discriminant  of  a  variant 
record  without  assigning  the  entire  record. 

EVR. 002(1201)  P2R. 013(104)  P2R. 015(402)  P2R. 046(401) 

3.7. E  Union  types  can  appear  only  as  variant  record  fields.  The  general 

union  type  approach  Is  preferred  over  variant  records.  XX3.3 

EVR .003(43.6)  P2R. 013(102)  P2R. 015(402)  P2R. 026(103)  P2R. 046(101) 

P2R. 046(107)  UR. 634 

3.7.  r  The  same  field  name  should  be  able  to  appear  In  different  variants 

of  a  record.  Representation  specifications  would  need  revision.  XX13.4 
UR .  018  LIR. 165  UR.  213 

3.7. G  Null  records  should  be  forbidden. 

LIR. 034 


3.7.H  There  should  be  a  dummy  field  name  for  constant  record  components 
which  are  never  referred  to. 

LIR. 457 

3.7.1  Only  one  dynamic  array  should  be  allowed  per  record,  and  it  should 
be  the  last  component,  as  for  variants.  Requiring  explicit  access 
implementations  for  the  general  case  makes  costs  more  apparent. 

LIR. 510 

3.7.1  Constant  Record  Components  and  Discriminants 


a 


3.7.1.  A  Eliminate  (non-deferred)  constant  raccrd  coaponants. 

OPA.017 

3.7.1. B  Constants  as  wall  as  deferred  constants  should  be  allowed  as 

discrlainants  of  records. 

LIR.149 

3.7.1. C  Define  ’complete  record  assignment*  explicitly. 

LIR. 511 

3. 7. 2.0  Dynaaie  arrays  should  causa  laaadlata  storage  overflow  if  their 
aaxlaua  size  is  too  great  (eg  Integer* Last) . 

LIR. 512 

3.7.2  Variant  Parts 

3. 7. 2.  A  There  should  be  a  way  to  set  a  record  discriminant,  presumably  in 
the  Unsafe  Programming  package.  XX13.10 

LIR .385 

3.7. 2.  B  Must  the  discriminant  variable  be  declared  in  the  record? 

LIR. 458 

3.7.3  Record  Aggregates  and  Discriminant  Constraints 

3.7. 3.  A  Discriminant  constraints  and  record  aggregates  are  semantically 
distinct  and  should  therefore  be  syntactically  distinct  as  well. 

LIR. 162 

3.7. 3.  B  All  deferred  constant  components  should  be  specifiable  through 
discriminant  constraint  specification.  XX3.7.1 

LIR. 588 

3.8  Access  Types 

3. 8.  A  Initialization  of  elements  of  access  types  should  not  be  regulred 
the  point  of  allocation. 

EVR.082 (#283)  P2R. 019(102)  OPA.005  LIR. 477 

3.8. B  There  should  be  a  free  operation  on  access  objects. 

EVR.003  (42.3)  EVR. 005CM.0)  LIR. 037  LIR. 127  LIR.  212 

LIR. 250  LIR. 408  LIR. 566 

3.8. C  It  should  be  possible  for  one  access  type  to  refer  directly  to 

another  access  type. 

P2R. 015(401) 

1.8. D  The  built-in  storage  allocation  mechanisms  are  much  too  restr'.ctlv 

and  do  not  allow  user-defined  mechanisms.  Extensive  proposals. 

LIR. 123  LIR.0S5 
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3.8.  t  The  rules  for  access  constants  (and  therefore  also  access  In 
parameta.-s)  severely  constrain  use  of  access  types;  nonetheless,  constants 
of  access  types  are  not  truly  read-only.  XX5.2.3  XX6.1 

HR. 181  UR. 132  UR. 200  LIR.216  LIR.538 

3.8. P  Discriminants  in  access  variables  should  be  changeable. 

UR.  055 

3.9. G  The  access  section  is  vague. 

UR.  102 

3.8.  H  It  should  be  clear  whether  there  Is  a  garbage  collector. 

C.IR. 233 

3.8.1  PL/I-like  separation  of  declaration  and  ‘allocation*  of  storage 
areas  is  preferred. 

UR  .  24* 

3.8. J  It  should  be  possible  to  point  to  static  data. 

UR.  337  UR.  390  UR.  414 

3.8.  K  Conversion  to  ancestral  type  of  an  object  of  derived  access  type 
can  violate  strong  typing  and  create  dangling  references.  XX3.4 

UR. 348 

3.8. L  There  should  be  provision  for  allocating  access-type  objects  at 

compile  time  when  passible. 

UR.41S 

3.8. M  It  would  be  nice  if  access  types  could  be  efficient  for  tightly 
packed  data,  using  pointers  into  fields  of  a  word  and  minimal-length 
pointers. 

UR.  417 

3.8. N  Any  variable  or  field  of  access  type  should  be  initialized  to  Null 

if  it  Is  not  explicitly  initialized  at  declaration.  XX3.2 

EVR. 802(1203)  P2R. 019(102)  OPA.005  UR. 478 

3.8.0  A  reference  count  scheme  should  be  used  for  deallocation.  (?) 

UR.  479 

3.8.  P  Access  type  model  preferred  to  traditional  pointers. 

UR  .181 

3.8.0  Anonymous  access  types  are  aoparently  useless.  Shouldn't  they 
therefore  be  illegal  (either  in  the  syntax  or  the  semantics)?  XX3.3 
UR.  201 


4.  NAMES,  VARIABLES,  AND  EXPRESSIONS 
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4.0. A  Functions'  valuss  cannot  bs  subscripted,  sliced,  or  selected. 

UR. 097  LIR.156 

4.1  Names 

4.1.  A  In  the  case  of  generic  parameters,  generic  associations,  and  renam: 
declarations,  the  syntax  is  presently  incomplete.  The  syntax  formula 
•fname.ldeslgnator*  does  not  cover  the  case  of  a  functional  attribute  such 
T'SUCC  or  T'ORD.  XXZ 

OPA.01S 

4.1. B  The  syntax  of  "name*  excludes  designators.  XX8.S  XX12.1  XX12.2 

LIR.136  HR.  225 

4.1. C  Subprogram  calls  (returning  access  types)  should  be  names. 

Consider  P(a).all  :»  .... 

UR. 271 

4.1.0  It  should  be  made  clear  that  a  name  cannot  be  used  for  more  than 
one  purpose  in  a  scope:  variable,  type,  function,  etc. 

LIR.483 


4.1.E  There  are  examples  of  'simple  names',  but  what  is  the  definition? 
LIR.S14 


4.1.F  Due  to  limitations  concerning  use  of  •designator",  it  would  not  be 
possible  to  use  stubs  within  the  subprogram  body  when  overloading  an  operat 
since  the  designator  cannot  subsequently  appear  in  tht  visibility  list  of  t 
sub-unit  body.  XX8.0 
UR. 203 

4.1.1  Indexed  Components 

4.1.2  Selected  Components 

4. 1.2.  A  Dot  selector  notation  can  productively  be  considered  a  variant 
syntax  of  function  calling. 

UR. 133 

4.1.2. B  Implicit  dereferencing  is  disliked. 

UR.  250 


4.1.2. C  The  concept  of  user-defined  type  attribute  is  unnecessary.  XXZ 

UR.  273  UR. 619 

4.1.2. D  Component  selection  syntax  should  be  uniform  with  that  of  function 

calling  and  array  indexing  <ie  parentheses). 

UR.  334 


4.1.2. B  Must  not  the  parenthesized  index  expression  of  an  array  level 
immediately  follow  the  array  identifier  and  precede  the  identifier  of  the 
next  level?  Say  so. 

UR.  490 


4.1.2. E  The  syntax  of  selected  components  provides  no  way  to  distinguish 

among  the  overloadings  of  a  name  by  signature  when  type  attributes  would  b* 
ambiguous.  XX3.3  XX6.6 

LIR. 469  LIR. 515 

4.1.3  Predefined  attributes 

4. 1.3.  A  The  notation  for  user-defined  and  predefined  attributes  should  be 
the  same;  dot  notation  is  preferred. 

LIR. 034 

4.1.3. B  Editorial:  identifiers  are  not  subprograms,  but  their  names. 

LIR.491 

4.2  Literals 


4. 2.  A  Enumeration  literals  should  be  quoted  in  order  to  distinguish  them 
from  variables. 

LIR. 059  LIR. 153 

4.2. B  There  should  be  a  Null  value  for  all  types,  which  would  cause  an 

exception  to  be  raised  if  calculated  with.  XX11.1 

LIR. 343 

4.2. C  User-defined  literals  are  needed.  Currertly,  too  many  explicit 

conversions  are  needed  (consider  private  types).  XX4.6  XX7.4 

LIR. 186 

4.3  Variables 


4. 3.  A  Suggests  that  'name'  Include  '<name>  .  all’,  and  ‘name’  be  substict 
for  'variable*  in  the  definition  of  ’primary’,  thus  eliminating  the  syncact 
term  'variable'. 

LIR. 272 

4.3. B  Slicing  is  clumsy:  start  and  length  ranges  and  default  endpoint 

ranges  are  desired,  le  arr(first  loc  SIZE  len)  and  arr (. .cutoff ) . 

LIR. 338 


4.3. C  .value  or  .val  preferred  over  .all. 

LIR. 356 

4.3. D  Clarify  the  syntax  and  description  of  Slice  variable.  Name,  and 

Variable.  ” 

LIR.455 

4.3. E  An  access  variable  should  denote  the  object,  not  the  access.  A 

special  syntax  should  be  used  for  access  assignment. 

LIR. 480 

4.3. P 
LIR. 481 


Replace  array. all  with  arrayfall).  (7) 
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4.4  Expressions 

4. 4.  A  Regarding  an  expression  as  possibly  a  one-component  aggregate  of  1; 

type  leads  to  ambiguities,  difficulty  of  implementation,  and  opaque  code. 
XX2.S  • 

LIR. 067  LIR. 085  HR. 494 

4.4. B  Some  easy  way  to  perform  such  operations  as  incrementation  Is 

desired.  The  suggestion . is  a  primary  'self'  or  as  a  shorthand  on  the 

right  hand  of  an  assignment  for  the  left  hand  side,  thus  var:»self+l.  XX5.i 
LIR.261  LIX.378 

4.5  Operators  and  Expression  Evaluation 

4.5. A  The  precedence  rules  for  user  defined  operators  are  the  same  as  the 

for  the  built-in  operators.  The  lack  of  implicit  semantics  for  overloaded 
operators  can  lead  to  programming  errors. 

P2R. 810(491) 

4.5.8  The  primitive  floating  point  operations  of  floor,  fraction,  and 
modulus  are  missing  and  cannot  correctly  be  implemented  within  the  language 
XXC 

LIR.1H4 


4.5. C  Expression  evaluation  order  should  be  left  to  the  compiler. 

LIR. 835  UR. 098 

4.5.0  The  relational  operators  should  be  represented  by  alphabetical 
keywords  rather  than  graphics  and  graphic  digraphs.  Suggests  £Q,  NE,  LT 
etc.  Also  suggests  making  all  operators  the  same  length.  XX2.2 
Lin. 307 

4.5. E  The  basic  bitstring  operations  And,  Or,  Shift,  and  Rotate  are 

lacking.  XX3.3 

LIR. 342 


4.5.P  Unary  operators  should  have  the  highest  precedence. 
LIR. 357 


4.5.G  Expressions  should  have  their  mathematical  meaning,  with  order  of 
evaluation  left  unspecified,  except  that  parentheses  should  restrict  that 
order,  and  a  pragma  should  be  provided  to  cause  code  to  choose  the  most 
accurate  evaluation  order  at  runtime. 

LIR. 438 


4.5.H  The  types  of  the  two  operands  of  logical,  adding,  and  multiplying 
operators  should  presumably  be  the  same  (but  cf.  fixed-point  multiply). 

LIR. 516 

4.5.1  Undefined  sequences  of  operator  characters  should  be  operator 

lexemes  definable  by  the  user  (having  some  fixed  precedence).  Consider,  ec 
XX2.2  XX5.1 

LIR. 594  LIR. 627 


4.5. J  Why  are  In  and  Not  In  omitted  from  the  operator  (precedence)  table' 

Is  this  to  imply  that  they  ara  not  overloadable?  XX4.5.2 

LIR.217  LIR.605 

4.5. K  Operators  with  partial  evaluation  (cf.  And  then)  are  desired:  a  Imf 

*»  Not  a  OrElse  b;  a  Default  b  *»  if  not  null(a)  then  a  else  b.  XX5.4.1 
LIR.192 


4.5.L  The  non-terminals  Exponentiating  operator  and  Logical  operator  are 
never  used.  XX4.4  “  ~ 

CIR. 217 

4.5.1  Logical  Operators 

4. 5.1.  A  Precedence  rules  for  “And*  and  “0r“  should  be  defined. 

EVR . 004  ( #4)  P2R. 044(403)  LIR.230  LIR.437  LIR.448 

4.5. 1. B  Can  logical  operators  have  boolean  arrays  of  differing  bounds  as 
operands?:  what  are  the  result'3  bounds?  (?) 

LIR.517 

4.5.2  Relational  and  Membership  Operators 

4. 5. 2.  A  The  definition  of  any  one  of  the  four  ordering  operations  should 
automatically  define  the  other  three  so  that  A>B  iff  B<At  A>»B  iff  not  A<B , 
A<»B  iff  not  B<A. 

EVR. 002(4204)  P2R. 038(407) 

4.5.2. B  The  implicitly  defined  aggregate  equality  should  be  defined  in  tern 

of  the  equality  of  its  component  types. 

EVR. 002(4205)  EVR . 007 (s2. 7)  LIR.00S(p02)  OPA.003 

4.5.2. C  If  a  component  of  a  composite  type  is  of  a  restricted  type 

assignment  is  r.ot  defined  for  the  composite  type.  If  a  component  of  a 
composite  typo  is  of  a  restricted  type,  comparison  for  equality  or  lnequali 
is  not  defined  for  the  composite  type  (unless  equality  is  defined  expllcitl 
in  the  package  defining  the  type) . 

OPA.004 


4.5.2. D  Presumably,  a  “corresponding  range..."  means  one  of  the  same  type 

as  the  first  argument  to  In.  (4-7  line  13) 

LIR.585 

4.5.3  Adding  Operators 

4. 5. 3.  A  Catenation  should  apply  to  bitstrings. 

LIR.245 


4.5.3.B  What  is  meant  by  “the  accuracy  of  the  result  is  the  accuracy  of 
the  operand  type*?:  the  type's  constraint,  or  the  mathematically  determlnec 
accuracy?  What  is  the  accuracy  of  an  operation  between  two  values  of  the 
same  type  but  different  accuracy  constraint? 

LIR.518  LIR.R05 
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4.5.4  Unary  Operators 

4.5.5  Multiplying  Operators 

4. 5. 5.  A  The  definitions  of  nod  and  Integer  division  violate  tile 
mathematical  property  a  mod  b  ■  (a-b)  mod  b.  The  current  operation  Is  In 
fact  'the  'remainder*  operation:  both  are  needed. 

EVR.  007  (s2. 5)  P2R.  025(482)  P2R.038  (#01)  P2R.  846(419)  LIR.010 
LIR.079  LIR.104  LIR.042  LIR.079  LIR.176 

LIR.317  MR.  358 

4.5.5. B  Hod  and  Rem  should  be  functions,  not  infix  operators. 

LIR.317 


4.5.5. C  Mod  should  be  everywhere  well-defined. 

LIR.439 

4.5.5. D  Presumably  fixed-point  values  of  different  type  can  be 

multiplied.  XX4.5 

LIR.S16 


4.5.5. E  To  multiply  values  of  distinct  fixed-point  types,  you  apparently 

have  to  convert  them,  which  loses  accuracy:  qualification  of  the  result  she 
be  sufficient.  XX3.5.S 

LIR.195 

4.5.8  Exponentiating  Operator 

4. 5. 8.  A  In  Integer**x,  must  x  be  positive  (per  4.5.8)  or  non-negative 
(per  C-1)?  XXC 

LIR.519 

4.8  Qualified  Expressions 

4. 6. A  The  notation  'type_name  (...)*  is  used  both  for  resolving  amblgult;, 
and  for  explicit  conversion,  which  can  confuse  the  meaning  of  widely 
different  semantics.  Bad  interactions  with  parameter  semantics. 

LIR.au  LIR.lll 

4.8. B  The  syntax  can  lead  to  ambiguous  expressions. 

LIR.162 

4.5. C  It  should  be  possible  to  overload  type  names  as  conversion 

functions.  XX6.6 

LIR.418 

4.8. D  Parenthesis  notation  Is  confusing,  cf.  use  of  *.*.  (??) 

LIR.483 

4.6.  E  There  should  be  some  way  to  convert  to  the  underlying  type  without 

knowing  Its  name.  This  Is  particularly  useful  for  private  types  in  their 
own  modules  to  reduce  the  effects  of  a  representation  change. 

LIR.599 


mr*  •.*'  «r*j— — ■"-'--t*-' ----- fc*  'ffr  xeTiyiT-yrxf-*-' ***=*»*.■«■•* 
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4.6.F  Why  are  derived  type  conversion*  not  allowed  on  the  left-hand  side 
assignments? 


$  4.8.1  Explicit  Type  or  Subtype  Specification 

*  4. 6.1. A  It  is  hard  to  see  when  qualification  would  Indeed  be  needed  in  tl 
Instr  Code(Flx)  case — presumably  I  has  soee  type,  which  would  disambiguate 
Fix,  unless  perhaps  I  is  an  overloaded  function  of  no  arguments,  certainly 
rather  obscure  case  for  an  examplel  Consider  using  the  example  of  the  ranc 
part  of  an  array  declaration. 

LIR. 520 

4.8.2  Type  Conversions 

4.8. 2. A  The  semantics  of  real-integer  conversion  are  left  vague. 

LIR. 105  LIR. 521 

4.7  Allocators 


4. 7.  A  Does  New  supply  additional  storage  or  provide  a  pointer  into  a 
predefined  area  set  up  by  the  compiler? 

P2R. 804(103) 

4. 7.  a  In  present  Ada,  an  allocator  must  provide  initialization  of 
dynamically  allocated  objects.  Consider  the  possibility  of  providing  a  pat 
aggregate  limited  to  discriminants  (as  for  constraints). 

OPA.006  LIR.  183  HR.  589 

4.7. C  The  user  should  be  able  to  define  his  own  allocator,  and  redefine 

the  system  allocator  for  his  own  types. 

LIR. 055  LIR. 025 

4.7. D  The  Keyword  *new*  is  overused:  for  allocation,  generic 

Instantiation,  and  type  derivation.  XX3. 3  XX12.2 

LIR. 025  LIR. 508 

4.7. E  Storage  areas  as  well  as  individual  objects  should  be  explicitly 

allocated  at  runtime  independent  of  declarations. 

LIR. 248 


4.7. F  It  should  be  possible  to  allocate  without  initialising. 

LIR. 477 

4.8  Static  Expressions 

4. 8.  A  The  language  definition  should  make  it  clear  that  static  expresslor 
may  be  used  everywhere  literals  may.  Static  expressions  should  be  just  the 
expressions  evaluable  at  compile  or  load  time.  The  value  of  constants  canr 
always  be  determined  before  the  corresponding  scope  entry.  Similarly, 
predefined  operators,  functions,  and  attributes  are  not  always  compile  time 
evaluable.  Static  expressions  should  not  be  restricted  to  predefined 
operations,  functions,  and  types.  The  definition  of  types  is  always  known 
during  compilation.  User  defined  functions  are  compile  time  evaluable  undt 
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the  imi  cl rcumstances  as  predefined  ones. 

EVR. 002  (>107)  COM. M3 

4.8.8  Cass  (f)  should  presumably  bs  rsstrlctad  eo  constants  Initialized 
by  static  expressions  and  static  indices  In  indexed  cosponants. 

UR.  522 


4.8.C  Despite  (d) ,  not  all  pradsfinod  attrlbutas  ara  static. 
LIR.217 


5.  STATEMENTS 


5.8.B  Prasant  Ada  forbids  go  to  out  of  a  block  but  parsltS  axlt  and  ratu: 
statements.  taplasantatlon  problaas  axlst  whan  thara  ara  tasks  local  to  t! 
block. 

0PA.M1 


5.0.C  Sequences  of  statements  should  ba  allowad  to  hava  a  value,  tha 
valua  of  tha  last  axprasslon/statasant.  XXS.4 
UR. 341 

5.1  Asslqnsant  Statasants 

5.1.  A  Tha  prohibition  against  alearlng  discriminants  of  accass  variables 
Is  a  confusing  Irregularity. 

L1R.008 (s2. 2) 

5.1. C  Tha  symbol  •••  should  ba  used  for  assignment. 

UR. 315 

5.1. D  Thara  should  ba  an  'exchange'  operator, 

UR.  377 


5.1. E  Thara  should  ba  aultiple  asslgnsant,  'a,b:«3':  compute  all 

destinations  befor*  any  assignments. 

LIR.141  UR. 432 

5.1. P  It  should  ba  possible  to  combine  a  binary  operator  with  assignment 

la  Algol-48,  C) ,  thus  x:*>2  doubles  x.  This  Is  particularly  useful  with  1< 
left-hand  sides.  XX4.4 

UR. 468  UR. 614 

5.1.1  Array  and  Slice  Assignments 

5.1.1.  A  Overlapping  slice  assignment  should  ba  permitted,  with  copy 
semantics. 

UR.  092 


UR.  257 
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5.1.1.B  la  assignment  between  variables  of  the  same  multidimensional 

array  type  with  Indices  specified  by  type  marks  and  with  the  same  number  ot 
components,  always  allowed  even  If  the  arrays  are  of  different  shape?  If 
multidimensional  arrays  are  considered  strictly  equivalent  to  an  array  of 
subarrays,  the  problem  does  not  arise.  XX3.6 
LIB. 523 

S.1.2  Record  Assignments 


5. 1.2.  A  The  current  rule  allows  the  discriminant  of  a  record  within  a  recor 
denoted  by  an  access  variable  to  be  altered.  Is  this  a  loophole? 

HR. 210 

5.2  Subprogram  Calls 

5. 2.  A  Thera  are  too  many  ways  to  make  a  procedure  call  and  define  aggregc 
values. 

P2R. 015(404) 


5.2.B  A  subprog ram_cal l_sta tenant  should  be  explicitly  forbidden  or 
explicitly  permltted“to  call  a  function  or  a  value  returning  procedure. 
LIR.021 (p02) 


5.2.1  Actual  Parameter  Associations 

5. 2.1. A  The  indication  of  parameter  mode  on  call  should  be  required  even 
without  keyword  association. 

LIR.2K2 


5.2.1. B  Keyword  parameter  association  is  liked. 

LIR.2A7 

5.2.1. C  Parameter  mode  in  calls  and  specifications  should  have  similar 

syntax.  In,  etc.  preferred  for  both. 

LIR.329 

5.2.1. D  Mode  should  not  be  distinguished  In  actual  parameter  syntax. 

LIR.347 


5.2.1. E  what  Is  the  definition  of  a  'qualified  variable*?  XX4.6 

LIR.524 

5.2.1. P  The  order  of  evaluation  of  subprogram  parameters  should  be  specific 

as  undefined  to  allow  optimization  and  reduce  the  complications  Implied  by 
variety  of  calling  syntaces. 

LIR.214 


5.2.2  Omission  of  Actual  Parameters 

5. 2. 2. A  There  should  be  some  placeholder  argument  specifying  the  default 
value  and  not  requiring  naming  the  remaining  positional  parameters. 
LIR.5S8 


X 
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5.7.3  Restrictions  on  Subprogram  Calls 

5. 2. 3.  A  The  aliasing  restriction  should  bo  statically  defined. 

UR. 082  LIR.158 

5. 2. 3.8  All  aliasing  should  bo  prohibited. 

UR.  1SS 

5.2.3. C  Aliasing  via  parameter  passing  should  be  allowed. 

UR.  368 

5.2.3. D  Aliasing  by  way  of  access  objects  Is  Inevitable  and  undetectable. 

It  should  not  be  prohibited. 

UR.  538 

5.2.3. E  How  strict  Is  aliasing  detection? 

UR. 581 

5.3  Return  Statements 

5.4  If  Statements 

5. 4.  A  When  can  a  type  derived  fron  Boolean  not  function  as  a  condition  lr 
If  statements?  XX3.S.3 

UR.  030 

5.4. B  Conditionals  should  be  allowed  as  expressions.  XX4.4  XX5.5 

UR.  340  UR.  595  UR.  635 

5.4. C  There  shocld  be  some  way  besides  Goto  to  have  common  actions  In 

branches  of  an  If:  else  Else  construct  suggested. 

UR.  434 

5.4.0  There  should  l>e  a  simple  syntax  for  multiple  End  If's:  End  If  *  3? 
UR. 434 

5.4.1  short  Circuit  Conditions 

5.4.1.  A  ‘And  then*  and  *cr  else*  should  be  allowed  in  any  boolean 
expression:  current  syntax  within  if  statements  does  not  even  allow  group!: 
with  parentheses.  Their  precedence  should  be  specified.  Note  also  that 
current  syntax  Is  not  LALRfl)  unless  And  then  Is  made  a  special  case  in  th* 
lexical  analysis. 

P2R. 039(404)  P2R. 043(411  P2R. 046(418)  UR. 121  UR. 192 

UR.  199  UR. 443  UR. 608 

5.4. 1. B  Since  the  compiler  should  feel  free  to  reorder  evaluation,  *and 
then*  and  *or  else*  are  superfluous:  they  should  be  the  normal 
Interpret".!  !on  of  "and*  and  *or*. 

UR.  035  UR.  050  UR.  073  UR.  243  UR.  230 

UR.  274 


-  ‘A  - 

5.4. 1. C  Although  partial  evaluation  of  boolean  expressions  should  be  the 
rule  In  conditionals,  full  evaluation  should  be  the  rule  in  expressions. 
LIR.243 

5.4.1. D  Short-circuit  conditions  should  be  named  “and"  and  *or*;  boolean 

operations  should  be  called  "&a  and  *1*.  XX4.S.1 

LIR.205 

S.5  Case  Statements 

5. 5.  A  Ada  requires  non-manifest  expressions  as  selectors.  This  restrict 
the  order  of  testing  which  degrades  optimization. 

P2R .039(411)  P2R. 046(417) 

5.5. B  Does  the  keyword  "of"  add  anything  useful  to  the  form  of  this 

statement? 

P2R. 019(407)  P2R. 039(422) 

5.5. C  Change  the  syntax.  Suggests  Pick. ..When  »>  .... 

LIR.389 

5.4  Loop  Statements 

5 . 6 .  A  An  Until  condition  Loop  statement  should  be  added  to  the  language. 

P2R. 019(40fi)  LIH.065 

5.6. B  A  variable  increment  should  be  specifiable  on  a  Loop. 

P2R. 019(409)  LIR.012  LIR.044 

5.6. C  While  Is  unnecessary:  Exit  suffices. 

P2R. 033(401)  LXR.251  LIR.275 

5.6. D  It  should  be  possible  to  define  and  use  loop  Indices  outside  the 

loop:  currently,  their  scope  is  unclear  and  seemingly  not  very  useful. 

P2R. 035(405)  LIR.044 

5.fi. E  Loop  labels  should  not  look  like  Goto  labels:  nor  should  their 
scope  extend  outside  the  loop  body.  What  Is  the  identifier  in  *end  loop 
(Identifier) *? 

LIR.151  LIR.222  LIR.539  LIR.602  HR. 006 

LIR.S16  LIR.632 

5.6. P  For  loop  over  sets  desired.  XX3.3 

LIR.400 


5.6.G  Loop  parameters  should  be  accessible  to  (outside??)  exception 
handlers. 

LIR. 4  33 


5.6.H 

LIK.467 


Loop  Indices  should  require  explicit  declaration  as  such 
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5.6.1  Loop  Indices  should  be  of  type  Integer  if  not  otherwise  known  from 
context,  on  analogy  with  array  bounds,  as  should  other  ranges.  XX3.5  XX3.» 
LIR. 507 

5.6. J  User-defined  iterators  are  needed  for  abstraction:  this  may  imply  t 

need  for  functional  arguments  (one  LIR  says  yes,  the  other  no).  XX3.0 

LIR. 596  LIR. 634 

5.6. x  More  loop  types  are  wanted:  Until  (While  Not)  and  loop  test  at  the 

bottom. 

LIR. 185 

5 • 6. L  Loops  should  be  generalized  to  allow  actions  (’adjustments*  or 
‘epilogues*)  after  the  exit.  Loop  labels  would  no  longer  be  necessary. 
Perhaps  there  should  also  be  even  more  complex  loop  constructs.  Details. 
LIR. 194 

S.6.,4  If  the  loop  index  is  not  used,  it  should  not  have  to  be  written. 
LIR. 224 

5.7  Exit  Statements 

5. 7.  A  Add  Exit  Unless  to  Exit  When. 

P2R. 046(415) 

5.7. B  There  should  be  a  multiple-level  exit  with  an  argument  of  the  numbs 

of  levels. 

LIR. 145 

5.7. C  The  Exit  statement  is  unnecessary;  Goto  suffices. 

LIR. 242 

5 • 7 . D  Either  remove  When  or  generalize  it  to  Raise,  Return,  and  Goto. 

LIR. 382 

5.7. E  Allow  When  after  several  other  types  of  statements.  (Retracted) 

LIR. 024 

5.7. F  Keep  Exit',  but  remove  When. 

uIR.440 

5.7. G  The  loop  label  should  be  required  in  an  Exit;  thus,  if  the  loop  is 

anonymous,  it  is  patent  that  premature  exit  cannot  occur. 

LIR. 602  LIR. 632 

5.8  Goto  Statements 

5. 8.  A  Ada  allows  transfer  of  control  between  THEN  and  ELSE  clauses  in  an 
statement  and  alternative  sequence  of  the  case  statement. 

P2R. 035(402)  P2R. 037(402) 

5.8.8  The  scope  of  a  label  is  too  small,  asymmetric,  and  irregular. 

LIR. 112  LIR. 122  LIR. 548  LIR. 569  LIR. 617 
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5.8. C  Label  and  Goto  syntax  and  semantics  ara  unclear. 

LIR. 072 

5.8.0  Conventional  label  syntax  (*Label:*)  is  preferred. 

LIR.250 

5.8.  B  Replace  Goto  with  a  block  Exit  statement. 

LIR.324 

5.8.  t  Labels  are  presumably  in  a  name  space  entirely  distinct  from 
declared  identifiers. 

LIR.549 

5.8. G  Labels  should  be  declared  as  in  Pascal,  thus  clarifying  their  scop* 

LIR.617 

5.9  Assert  Statement 

5. 9.  A  Assertions  cannot  be  stated  to  hold  over  regions  of  programs;  nor  c 
they  be  quantified;  nor  can  they  refer  to  the  history  of  variables. 

LIR .033 

5.9. B  The  action  to  be  taken  when  assertions  are  not  satisfied  should  be 

controllable. 

LIR. 033 

5.9. C  The  assert_error  exception  is  unnecessary  and  dangerous,  since  it 

allows  violations  of  assertions  tu  influence  program  execution. 

LIR. 071 

5.9.0  The  assert  statement  is  unnecessary  and  inefficient. 

LIR. 244 

5.9.6  The  current  simple  assertion  facility  suffices. 

LIR. 209 


6,  DECLARATIVE  PARTS.  SUBPROGRAMS,  AND  BLOCKS 

6..  Declarative  Parts 


6.1.  A  Top-down  organization  of  declarations  is  precluded  by  the  linear 
elaboration  of  constituents  of  a  declarative  part.  XX8.4 

LIR. 447 

6.1. B  Enforced  divorce  of  declarations  and  representations  is  unnatural 

and  error-prone;  if  it  is  to  remain,  representations  should  follow  the  bod', 
not  precede  it.  Bodies  might  also  be  allowed  to  be  intermixed  with 
declarations.  XX6.1 

LIR. 525  LIR. 631 


6.1. C  There  is  a  syntactic  ambiguity  whereby  nodule_declaration  and 

modulo  specification  can  be  confuted.  ' 

UR. 54?  LIR.624 

6.1.0  The  grammar  should  express  the  (context-free)  restrictions 

on  declarative  parts  by  introducing  variants.  XX6.4  XX7.1  XX7.3  XX7.4  XX9. 
UR. 624 

6.1. E  Declarations  and  bodies  should  be  everywhere  intersperslbie. 

UR. 624 


6.1. P  Different  kinds  of  declarations  are  too  non-uniform  in  syntax:  in  s 

the  name  precedes.  In  others  it  follows,  a  terminal.  UR  prefers  consister 
use  of  name:declaration. 

UR.  625 

6.2  Subprogram  Declarations 

6. 2.  A  There  should  be  some  way  to  tell  the  compiler  that  a  subprogram  ne> 
not  be  compiled  to  be  reentrant  or  recursively  callable. 

UR. 632  UR. 639  EVR. 005 ( 4 1 1 . 0) 

6.2. B  LRM  does  not  specify  case  of  character-string  designators,  e.g.  'me 

UR.  034 


6.2.C  The  supposed  inefficiency  of  allowing  all  procedures  to  be  recursit 
or  reentrantly  callable  is  a  myth.  The  present  design  should  be  retained. 
UR. 166 


6.2.D  Comma  should  be  allowed  to  separata  parameters  in  procedure 
declarations  as  in  calls. 

UR. 322 


6.2.E  The  syntax  of  paraaeter_declaration  should  enforce  the  prohibition 
on  defaults  for  Out  and  In  Out  parameters. 

UR. 541 


6.2. P  There  should  be  functional  arguments.  XX3.0 

UR. 178  UR. 623 

6.2. G  Operators  should  have  a  nonterminal  in  order  to  tighten  up  the 

definition  of  designator.  The  quotes  around  them  appear  unnecessary. 
LIR.624  UR. 627 

6.3  Po rma 1  Parameters 


6. 3. A  The  semantics  of  parameter  passing  should  be  better  defined. 

Both  reference  and  copy  semantics  are  desired. 

EVR. 001 (p07)  EVR. 002(4102)  EVR. 003 (41 . 1)  EVR. 004(42)  EVR. 005 (48 . 0) 

EVR . 006 (s4 .a)  EVR. 007 (s2. 3)  P2R. 014(402)  P2R. 015(405)  P2R. 022(403) 

P2R. 02R (404)  P2R. 028(401)  P2R. 036(411)  P2R. 038(405)  P2R. 043(401) 

DCR.001  LIR.039 


6.3. B  Named  parameters  complicate  the  language  and  contribute  little. 

Defaulted  parameters  appear  dangerous:  accidental  omission  of  one  or  more- 
parameters  is  a  source  of  hard  to  find  errors. 

E  VR .003(13.5)  EVR.004 ( 16)  EVR. 805 (#6. 0)  P2R. 043(409)  OCR. 002 

6.3. C  Are  the  rules  for  type  checking  of  actual  against  formal  parameters 

well  defined?  Is  "treated  just  as  in  assignment"  sufficient? 

EVR.004 (#1) 

5.3. D  The  semantics  of  parameter  binding  should  be  defined.  The  deflnlci 

should  be  by  copy  only. 

LIR.01?(p01)  DCR.001 

6.3. E  Allow  certain  formal  and  actual  names  to  be  marked  as  volatile 

depending  on  their  behavior.  Allow  the  translator  to  bind  all 
non-volatile  objects  by  reference  if  it  can  thereby  gain  efficiency. 

LIR. 01? (p03) 

6.1. F  Parameter  passing  semantics  should  be  more  precisely  defined 

in  terms  of  copying;  reference  passing  would  be  considered  an  lmplementatic 
that  compilers  may  use  when  it  does  nut  affect  the  meaning  of  the  program. 
If  this  optimization  is  to  be  of  reasonable  applicability,  it  may  be 
necessary  to  mark  variables  shared  by  several  tasks. 

OPA.011  DCR.001 

6. 3. G  We  do  not  need  both  keyword  and  positional  parameters. 

PJR. 012(405)  DCR.002  LIR. 087 

6.3. H  There  is  some  redundancy  is  giving  three  parameter  binding  classes: 

IN,  OUT,  IN-OUT. 

P2R. 033(402) 

4.3.1  Programs  should  be  able  to  parse  their  own  parameter  lists. 

LIR. 130 

6.3. J  LIR  considers  the  semantics  of  In  parameters  vague. 

LIR. 077 

6. 3. K  All  Out  parameters  should  be  strictly  undefined  after  unhandled 
exceptions. 

LIR.0B4 

6.3. L  Default  parameters  have  poorly-defined  evaluation  time:  the  default 

value  should  be  calculated  at  the  point  of  call. 

LIR. 143 

6.3. M  Default  values  for  in  out  and  out  parameters  should  be  allowed: 

for  in  out,  the  default  would  be  used  for  in  and  ignored  on  out;  for  out 
it  would  be  the  out  value  if  no  other  value  were  given. 

LIR. 164 
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6.3.0  The  current  copy  senantlcs  are  good.  The  LRH  should  specify  the 
conditions  under  which  reference  lapleaentation  will  be  'safe'. 

LIR. 256 


6.3. P  There  should  be  ways  to  farce  reference  and  copy  binding. 

HR. 450 

6.3.0  Can  a  formal  Out  parameter  be  read  after  being  assigned  to? 

LIR. 542 

6.3. R  Constraints  on  actuals  should  not  constrain  formals:  they  should  b< 

checked  on  return.  XX3.3 

LIR.543 

6.3.S  Reference  binding  is  not  compatible  with  portability  across 
architectures. 

LIR.161 


6.3. T  The  subprogram  specification  should  be  able  to  enforce  keyword  or 

positional  form  of  call  for  uniformity's  sake. 

LIR. 190 

6.4  Subprogram  Bodies 

6. 4.  A  What  are  ’Identical  subprogram  specifications*  in  this  context? 
L1R.034 

6.4. B  Semantics  of  ’Inline’  are  vjgue  and  inefficient,  and  hard  to  impleir 

for  recursive  or  separate  subprograms;  a  macro  preprocessor  Is  preferred. 
LIR .045 

6.4. C  Can  recursive  programs  be  Inline? 

LIR. 544 


6.4.D  What  is  the  rule  of  equivalence  between  subprogram  bodies  and 

declarations?  Presumably,  it  does  not  distinguish  X:T  and  X:ln  T,  but  does 
distinguish  X,Y;  T  :*  expr  and  X;  T  :»  expr;  Y:  T  ?*  expr  (consider  side 
effects).  Presumably  types  are  differentiated  by  meaning,  not  by  name. 

(Signature  issue) 

LIR. 217  LIR. 545 

6.4. D  The  note  about  Inline  appears  to  preclude  inline  expansion  when  it 

not  requested:  compilers  might  well  want  to  expand,  eg,  subprograms  called 
once. 

LIR. 605 

| 

6.4. E  In  there  any  difference  between  the  elaboration  and  the  execution  c  j 

a  program?  ■ 

LIR. 605 

6.4. P  The  conformity  among  unit  bodies  could  be  emphasized  through  a  comr 

syntactic  category.  XX6.7  XX7.1 
LIR. 624 
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6.5  Punction  Subprograms 


6. 5.  A  Ths  user  should  bs  abls  to  designate  ths  difference  between  those 
side  effects  (l.a.,  raf trances  and  assignments  to  non-local  variables)  of 
functions  for  which  the  Implementation  preserve  the  ordor  and  number  of 
occurrences,  and  those  for  which  the  Implementation  need  not. 

EVR. 001 (p08)  EVR. 002(0105)  EVR. 006 (s4.d)  POS.003(p01)  P2R.037 (004) 

?2R. 039(110)  LIR. 005 (p01 ) 

6.5.8  It  Is  not  necessary  to  restrict  calls  to  value  returning  procedures 
to  assignment  statements.  Initializations,  and  procedure  calls. 

EVR. 003(11. 5)  EVR. 004(17)  EVR . 006 (s4 . c )  EVR . 007 (S2.8)  P2R. 026(008) 

LIR . 005 (p06 )  LIR. 141 

6.5. C  Functions  should  be  allowed  to  perform  storage  management. 

EVR. 002(0105]  LIR. 085 (p04)  LIR.006(p04) 

6.5. D  The  present  definition  of  functions  and  value  returning  procedures 

does  not  appear  simple  to  explain  or  to  use. 

OPA.008 

6.5. E  Functions  and  VRP's  should  not  be  distinguished. 

LIR. 035  LIR. 075 

6.5. F  No_value_error  should  be  raised  In  the  caller's  environment. 

LIR. 088 

6.5. G  The  distinction  between  VRP's  and  functions  is  good. 

LIR. 253 

6.5. H  VRP's  should  be  allowed  Out  parameters. 

LIR. 344 

6.5.1  Functions  with  side  effects  are  useful.  Perhaps  best  eliminate 
VRP's  and  add  a  side-effects  pragma  for  functions. 

LIR. 431 

6.5. J  No_value_error  for  function  values  should  be  checked  statically  anc 

thus  not  be  an  exception. 

LIR. 546 

6.5. K  VRP's  should  be  allowed  anywhere  functions  are  allowed;  they  should 

also  be  allowed  Out  parameters  (consider  file  var'ables). 

LIR. 141 

6.6  Overloading  of  Subprograms 


6. 6. A  Overload  resolution  should  be  simplified:  parameter  names  should  nc 
be  used  in  overload  resolution;  type  and  order  of  unnamed  actual  parameters 
should  be  used.  The  meaning  of  'ambiguous*  calls  on  overload  definitions 
should  be  clearly  defined  by  the  language,  not  Implementations. 

EVR .001 (p08)  EVR. 002(0108)  EVR . 003 { 0 1 . 6)  EVR. 007 (s2. 1)  P2R. 037(005) 

P2R. 043(007)  OCR. 002  LIR. 131  LIR. 076  LIR. 087 
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6. 6. 8  Whan  potentially  conflicting  declaration*  appear  In  the  Sana  local 

scope  they  should  be  Illegal  at  the  point  of  declaration. 

EVR.082(#108)  OCR.  082 

6.6.0  It  is  unreasonable  when  outputting  a  single  character  to  require 
Put (String  (*A")).  The  TEXT  10  overloaded  procedure  Put  at  present  forces 
this.  — 

LIR. 021 (p03) 

6.6.  E  There  should  be  no  overloading  on  result  type. 

LIR. 277 

6.6. P  Are  defaults  part  of  the  subprogram  signature? 

LIR. 547 

6.6. G  The  overloading  resolution  rules  should  be  clarified. 

LIR. 582 

6.6.  H  Accidental  overloading  teens  likely  (especially  with  use  of 
libraries);  this  will  weaken  type  safety.  Is  prevention  to  be  left  to 
utilities? 

LIR. 131  Ln.562 


6.6.1  Entries  should  be  overloadable.  XX9.5 
LIR. 587 

6.6. J  There  should  be  overloading  resolution  changes  so  that  there  is  alv 

a  simple  and  unambiguous  way  of  calling  a  given  (especially  local)  procedui 
LIR. 076 

6.6. K  New  overloadings  can  change  the  meaning  of  programs.  Overloaded 

function  calls  are  hard  to  read.  Accidental  redeclaration  or  overloading  : 
too  easy.  Therefore,  overloading  should  be  resolved  by  Type  and  Order  onl>. 
non-default  parameters;  only  defaultable  parameters  should  be  passable  by  r 
redeclarations  must  be  restricted;  literals  and  parameterless  functions  mu; 
almost  always  be  qualified;  and  other  functions  may  not  be  overloaded  on  r* 
type.  XX6.3 

LIR. 132 


Overloading  of  Operators 


6.6.1. A  When  one  overloads  «,  the  operator  /•  Is  automatically 

overloaded.  Does  any  similar  relation  exist  between  <  and  >»  or  >  and  <■? 
P2R. 046(422)  LIR. 269 
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•6. 1. B  The  properties  expected  of  functions  overloading  built-in  operators 
should  be  defined  by  the  language  (eg,  <  returns  boolean;  *  is  commutative: 
LIR. 114  LIR. 269 


6.6. l.C  Assignment  should  be  overloadable.  Consider  'receive*  as  a 
parameter  mode.  XX5.1 
EVR.003 (13.2)  LIR. 006 (p02)  LIR. 034 


LIR. 586 


6.6. 1.0  It  nay  ba  desirably  Co  provide  not-predefined  overloadable 
built-in  operators,  using  symbols  such  as  ++,  at,  //. 

LIR. 269 

(5.6.1.E  What  exactly  are  the  overloadable  operators?  (In?)  XX4.S.2 
LIR. 217 

6.7  Blocks 

*• 7. A  tt  should  be  possible  to  name  all  blocks,  perhaps  uniformly  with 
loops.  XX5.6 
LIR. 066  LIR.222 

5.7. B  Declare. . .begin. . .end  is  too  verbose:  a  conclser  form  is  preferred. 

LIR. 339 

4.7. C  Blocks  should  be  allowed  visibility  clauses.  XX8.3 

LIR.484 


7.  MODULES 


7.0. A  When  are  package  bodies  elaborated? 

LIR. 095 

7.0.B  Packages  with  mutually  dependent  initializations  have  poorly  define 
semantics. 

LIR. 096 

7.0.C  Packages,  subprograms,  and  tasks  should  be  made  more  similar: 
Initiate  should  have  the  syntax  of  subprogram  call;  the  visible  part  of  a 
task  should  allow  variable  and  module  declarations;  it  should  be  possible  t 
Initiate  packages;  subprogram  and  module  should  have  the  sane  syntax  (the 
formal_part  should  occur  at  the  end  of  the  visible  part);  visibility  shoulc 
be  specifiable  for  subprograms.  XX6.0  XX9.0 
LIR. 279 

7.0.C  The  military  standard  ’module"  differs  from  the  Ada  module: 
military  standard  modules  are  compilation  units. 

LIR. 323 

7.0.D  A  package  specification  should  be  able  to  be  associated  with  more 
than  one  body,  with  a  choice  at  link  tl.ae.  XX10.0 
LIR. 411 

7.1  Module  Structure 

7.1. A  Data  blocking  in  meaningful  groups  and  specification  of  data  block: 
on  Import  and  export  lists  should  be  allowed. 

P2R. 035(406) 
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7.1. B  The  semicolons  In  the  syntax  of  module_decl  and  module_spec  ara 

lnconsistsnt  with  thair  subprogram  analogues.  ~ 

LIR. 051 

7.1. C  Thara  should  always  ba  a  aodula body,  even  If  only  "null";  this 

simplifies  linker  and  library  management. 

LIR. 310 

7.1.0  What  ara  the  semantics  of  packaged  data  in  the  presence  of 
reantrancy? 

LIR. 460 

7.1. B  Module  specifications  should  not  ba  differentiated  as  Package  and 

Task—this  distinction  should  ba  made  only  in  the  body.  Procedures  and  ant 
should  not  ba  differentiated  in  the  specification  part:  the  linker  can  tak* 
care  of  any  seoarate  compilation  problems. 

LIR. 187  LIR. 188 

7.2  Module  Specifications 

7. 2.  A  Specifications  and  program  should  not  be  separable:  a  textual  inset 
mechanism  should  be  used  for  common  declarations. 

LIR. 247 

7.3  Module  Bodies 


7. 3. A  Direct  nesting  of  modules  confuses  visibility  badly  with  no  increat 
in  functionality. 

LIR. 068  LIR. 198  | 


7.4  Private  Type  Declarations 

7. 4. A  The  inability  to  parameterize  private  types  for  diefining  constraint 
causes  problems  with  type  composition.  XX3.0 
LIR. 008 (s3.0i  LIR. 142 


7.4. B  Generics  are  not  an  adequate  way  of  defining  constrainable  private 

types,  because  each  instantiation  gives  a  new  type. 

LIR. 008 (s3 . 2) 

7.4. C  Restrictions  on  operations  available  should  apply  to  private  type 

expressions  within  the  visible  part  in  which  the  type  is  defined. 

LIR. 034 


7.4. D  Package  specification  do  not  need  explicit  "private  parts":  the 

declaration  "type  x  is  private*  suffices;  all  else  should  be  In  the  body. 
LIR. 236  LIR. 583 

7.4. E  Can  literals  of  restricted  type  be  written  usirg  the  qualified 

expression  notation  outside  their  modules?  Presumably  not. 

LIR. 237 


/ 
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7.4 .F  Son*  *asl*r  way  of  Inheriting  operations  for  restricted  types  is 

desired,  eg,  'type  t  is...  inheriting 
UR.  268 

7 .4.0  Objects  of  restricted  private  type  should  be  required  to  be 

initialized  inside  their  type  definitions. 

UR.  384 

7.5  An  Illustrative  Table  Management  Package 


8.  VISIBILITY  ROLES 


8.1  Scope  of  Declarations 

8.1.  A  The  visibility  rules  should  be  sinplified.  There  should  be  uniforir 
visibility  rules  regardless  of  whether  a  definition  is  built-in,  predefined 
or  user-defined,  use  and  Restricted  should  not  treat  built-in  and  user- 
defined  definitions  differently. 

EVR . 082 (1214)  EVR. 883(43. 71  EVR . 885 (4 12. 8)  P2R. 814(4831  P2R. 026(413) 

P2R. 837(481)  P2R. 838(488)  P2R. 843(486) 

8.1.8  There  should  be  partial  import  for  management  control,  perspicacity 
and  improved  optimization. 

EVR. 883(42. 4)  EVR. 884(43)  P2R. 825(485)  P2R. 827(481)  P2R. 832(481) 

P2R. 836(484)  LIR.849  LIR.138  LIR.259  LIR.578 

8.1. C  There  should  be  a  partial  export  of  record  field  names;  this  would 

allow  information  hiding  In  the  Parnas  sene*.  Currently,  such  biding  is 
nearly  Impossible. 

EVR. 883(42. 5)  P2R. 836(484) 

8.1. D  There  should  be  Import  and  export  of  variables  as  read-only. 

EVR. 883(42. 6)  P2R. 832(402)  P2R. 836(485)  P2R. 839(412)  LIR.038 

UR. 234 

8.1. E  The  scope  rules  of  the  language  should  be  modified  to  closed  scop* 

instead  of  open  scop*.  This  would  support  maintainability. 

P2R. 836(402)  UR. 856 

8.1. P  There  should  be  partial  export  in  general. 

UR.  838  LIR.138 

8.1. C  The  scop*  of  Accept  formal  parameters  is  omitted;  it  presumably 

extends  from  the  declaration  to  the  end  of  the  Accept. 

LIR.280 

8.1. H  The  visibility  mechanism  as  a  whole  contributes  more  to  wrltability 

than  readability,  contradicting  the  design  goal  stated  in  l.i. 

LIR.578 
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8.1.1  The  terminology  used  in  describing  scope  is  confusing.  In  particular 
‘definitions*  should  not  have  ‘scopes',  ‘declarations*  should.  Visibility  ru: 
should  be  based  on  simple  principles,  listed  in  the  HR. 

LIR. 198 

8.2  Visibility  of  Identifiers 

8. 2. A  XX4.1  XX5.6  XXS.8 
LIR. 000 


8.2.B  The  note  on  redeclaration  is  apparently  extraneous:  an  inner 

declaration  of  an  object  hides  an  outer  declaration  of  a  homonymous  function 
regardless  of  types.  The  restriction  on  enuaeration  variables  la  also 
questionable. 

LIR.5S0 


8.2.C  It  is  not  clear  what  is  visible  where.  What  is  the  relation 

between  scope  and  visibility?  Is  an  enumeral  of  anonymous  type  defined  in  a 
record  declared  in  a  block  visible  in  the  body  of  the  block? 

LIR .551 


8.2.D  The  restrictions  on  redeclaration  may  be  good  style,  but  should  not  b* 
part  of  the  language.  These  restrictions  will  also  slow  the  compiler. 

LIR. 840 


8.2. E  Does  the  restriction  on  redeclaration  apply  to  the  visible  part  of  s 

module  specification,  the  private  part,  and  its  tody's  outermost  declarative 
part  considered  as  one  declaration  list? 

LIR. 21? 

8,3  Restricted  Program  Units 

8. 3.  A  Make  Restricted  mandatory  before  a  compilation  unit. 

LIR. 023 


8. 3.  B  The  keyword  ‘restricted*  is  used,  counterintuitively,  to  specify  what 
is  visible,  not  what  is  restricted. 

LIR. 041  LIR. 484 

8.3. C  Clarify  what  unit  names  msy  appear  in  a  visibility  list. 

LIR. 281  LIR. 552 

8.3. D  Use  often  forces  inclusion  In  the  Restricted  list.  The  functions 

of  Restricted  and  Use  should  be  reorganized  to  recognize  that  most  items  in 
Use  clauses  have  to  be  Imported. 

LIR. 303  LIR. 446 

8.3. E  Non-enclosing  sub-programs  (eg  library  units)  should  be  allowed  in 

visibility  lists.  XX10 

LIR. 435 
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8.3. P  Input  Output  seems  to  appear  in  a  visibility  l<at  where  it  la  not 

visible.  Is  this  because  it  is  a  'library*?  XX10.1 

LI?. 554 

8.3. G  Importations  can  be  hidden  deep  within  code.  There  should  be  some 

control  over  this. 

LIR. 570 


8.3. H  The  importation  and  visibility  restriction  functions  of  the 

restricted  list  should  be  separated.  The  first  name  restricts  scope;  all 
the  others  enlarge  it.  XX1J.2 

LIR. 128  LIR. 2*3  LIR. 604  LIR.611  LIR. 633 

8.4  Use  Clauses 

8. 4.  A  It  should  be  possible  for  a  use  clause  to  refer  to  a  modulo  declared 
in  the  same  declaration  part.  (Currently  the  use  clause  must  come  first  and 
there  are  no  forward  references.) 

P2R. 839(424)  LIR.219  LIR. 252 

8.4. B  Any  unambiguous  reference  to  Identifier)  should  be  permitted,  as  in 

PL/I ;  the  Use  clause  would  then  be  unnecessary. 

LIR.229 


8.4. C  It  should  be  possible  to  mix  Use  clauses  sith  declarations  freely. 

LIR.219  LIR. 2r2 

8.4. D  The  Use  clause  should  be  delete^  as  detrimental  to  readability:  an 

Improved  Rename  would  be  a  partial  replacement.  XX8.5 

LIR. 385 


8.4. E  Identifiers  rendered  ambiguous  because  of  the  Use  clause  should  be 

invisible  in  the  scope  of  the  invisibility. 

LIR. 553 

8.5  Renaming 

8. 5.  A  'Rename*  complicates  verification  and  aliasing  analysis. 

LIR. 159 


8.5.8  Rename  should  be  a  statement,  not  part  of  a  declarative  part.  XX5.0 
LIR. 302 

8.4  Predefined  Environment 

8. 4. A  The  Environment  pragma  greatly  complicates  visibility.  Remove  It 
or  at  least  clarify  its  effect. 

LIR. 454 


9.  TASKS 
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9.0. A  Tasks  intended  as  parallel  thraads  of  control  (“processes*)  and 
tasks  serving  to  synchronize  access  to  shared  data  objects  ("monitors*)  are 
logically  distinct  (with  different  implementation  strategies  as  weVl),  so 
the  determination  cannot  be  left  to  the  translator.  There  are  also 
difficulties  with  termination,  optimization,  and  recognition  with  the 
interface  task  approach. 

LIR. 009  LIR. 061 

9.0.B  A  task  defining  a  class  of  sharable  objects  should  be  considered 

as  a  data  type,  so  as  to  permit  naaed  Instances  of  such  objects  to  be  declare- 
to  be  Included  as  coaponents  of  other  deta  objects  and  to  be  passed  as 
parameters}  neither  task  families  nor  generics  are  adequate  for  this  purpose. 
LIR. 009 (s3. 1) 

9.0.C  Capabilities  for  specifying  the  low-level  implementation  of 

synchronization  disciplines  should  be  provided  without  forcing-  the  user  to 
abandon  the  basic  tasking  framework. 

LIR.009(s3.2) 

9.0.D  Allowing  unrestricted  access  to  (shared)  global  variables  Is  not 
only  unreliable  and/or  inefficient,  but  also  leaves  the  semantics  of  basic 
operations  (e.g.  assignment)  undefined  in  the  presence  of  concurrent  executio- 
LIR. 009 (S3. 4) 

9.0.E  The  absence  of  anonymous  tasks,  tasks  as  generic  parameters  and 
operations  applicable  to  all  tasks  (e.g.  suspend,  reschedule,  etc)  seems  to 
limit  capabilities. 

LIR. 009(34. 10) 

9.0.F  There  should  be  a  way  to  name  task  Invocations  and  to  control  them. 
EVR. 001 (p09 )  EVR .001 (pi 1 )  EVR. 002(4101)  EVR. 003(41. 2)  BVR. 005 ( 41 . 4) 

EVR.007(s2.6)  P2R. 013(406)  P2R.v.  4(409)  P2R. 018(403)  P2R. 018(408) 

P2R, 018(409)  P2R. 027(402)  P2R. 030(402)  P2R. 030(404)  P2R. 038(403) 

P2R. 04(5(409)  P2R. 04(5(410)  LIR. 124 

9.0.G  It  should  be  possible  to  achieve  efficient  and  safe  sharing  of 

variables.  Current  mechanisms  are  either  inefficient  or  unsafe.  Perhaps  the 
should  be  syntactic  brackets  of  critical  regions. 

EVR. 001 (p09)  EVR .001 (pi  2 )  EVR. 002(4106)  EVR. 003 (41.4)  EVR. 005 (41 . 2) 

EVR. 006 (34. e)  P2R. 006(403)  P2R. 012(402)  P2R. 014(409)  P2R. 019(401) 

P2R. 019(413)  P2R. 022(404)  P2R. 028(405)  P2R. 033(403)  P2R. 036(401) 

P2R. 039(414)  P2R. 043(402)  P2R. 043(403)  P2R. 046(414)  LIR. 147 

LIR. 453 

9.0.H  Test  and  set  and  spin-lock,  or  equivalent  functions,  are  desired. 

EVR. 002(4106)  EVR. 006 (s4 . e)  P2R. 004(401)  P2R. 018(403)  P2R. 018(405) 

P2R. 022(402)  P2R. 025(404)  P2R. 027(404)  P2R. 036(403)  P2R. 046(412) 

P2R. 046(413)  OPA.007  LIR. 147 

9.0.1  It  should  be  possible  for  the  user  to  write  and  use  tua  own  scheduler 
BVR. 007 (si . 2)  P2R. 003(401)  P2R. 018(402)  P2R. 018(406)  P2R. 025(404) 

P2R. 027(404)  P2R. 030(403)  P2R. 035(401)  LIR. 157 
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9.0.J  It  Is  not  possible  to  define  <•  full  pledged  event  abstraction  that 
can  guard  a  salact. 

P2R .018(104) 

9.0.K  It  should  ba  posslbla  to  handla  intarrupts  efficiently.  Tha  lnterrup 
information  channal  Is  now  connactad  to  a  task  antry.  What  is  required  is 
exacution  o f  interrupt  handling  not  under  scheduler  control. 

EVP .001 ( pi  2 )  EVP .003(12.2)  EVR . 006 (S4 .b)  EVR . 007 (Si . 2)  P2R. 001(101) 

P2R. 093(101)  P2R.015 (#09)  P2R. 017(102)  P2R.017{#03)  P2R.017(#04) 

P2R. 03fi (#09)  P2R.039(#18)  POS.001 

9.0.L  Tha  interrupt  lntarfaea  is  an  indorsation  channal;  what  Is  needed 
is  access  to  tha  fact  of  tha  interrunt  as  a  control  event. 

EVR . 001 (pi 2)  LIR.021 (p06)  POS.001  LIR.0S0 

9.0.K  There  is  difficulty  in  linking  a  faally  of  task  activations  with  a 
set  of  interrupts.  It  should  ba  possible  to  attach  tha  entry  point  of  a 
family  of  tasks  onto  an  arbitrary  sat  of  interrupt  addresses. 

P2R .039(118) 

9.0.N  The  capability  of  passing  parasetets  to  tasks  at  activation  time 
should  be  provided;  passing  them  via  entry/accapt  is  subject  to  waiting. 

EVR. 005 (#1.8) 

9.0.0  There  are  significant  problems  with  dynamic  tasking  on  distributed 
system  architectures. 

POS.002 


9.0.P  There  is  no  way  of  guaranteeing  indivisible  operations. 

LIR . 9fi0 

9.0.0  All  intertask  variable  access  should  be  forbidden;  communication 
should  be  accomplished  with  entry  and  function  calls.  This  simplifies 
semantics  and  extends  to  distributed  architectures. 

LIR .254 


5.0.R  Tasking  should  be  more  controllable; 
and  resumptivity. 

LIR. 248 


specification  of  preemptlvity 


9.0.S  Task  variables  are  needed  to  avoid  a  problem  with  the  visibility  of 
the  index  type  in  task  families. 

LIR. 282 


9.0.T  On  distributed  architectures,  it  should  be  possible  to  specify  the 
subsystem  on  which  to  run  a  particular  task  (as  part  of  Initiate?). 

LIR. 283 


9.0.U 
LIR. 354 


Suspend  and  resume  are  desired 


9.0.V  To  avoid  buffer  tasks,  thsrs  should  bs  a  prsdefinad  parameterized 
type  Qusus.  XX9.12 
LIR.373 

9.0.W  Too  many  buffer  tasks  art  seen  as  required.  The  proposed  solution 
is  a  mechanism  to  delegate  the  completion  of  an  ongoing  rendezvous  from  one 
task  to  another,  allowing  it  to  be  completed  in  the  second  task  and  freeing 
the  first  task.  Discussion. 

LIR.406 


9.0.X  If  task  families  are  to  substitute  for  task  variables,  there  should 

be  some  way  of  finding  how  many  members  of  the  family  are  active,  and  some 
way  to  get  the  index  of  an  inactive  one. 

LIR.407 


9.0.Y  Some  concept  of  channels  is  necessary  to  allow  configuration  of 
communication  lines  among  tasks  defined  in  a  library  at  system  generation. 
Otherwise,  either  the  software  must  be  rewritten  for  each  configuration,  or 
installation-dependent  communications  tasks  must  be  defined. 

LIR.590 


9.0.Z  Too  many  buffar  tasks  are  required.  There  should  be  a  variety  of 
entry  (with  In  parameters  only!  which  does  not  wait  for  completion  of  the 
rendezvous,  and  queues  entry  calls. 

LIR.S91  LIR.  510 

9.0.ZA  Task  variables  are  needed  so  that  a  server  task  can  reply  to  user 
tasks  which  are  not  members  of  the  same  task  family. 

LIR. 592 


9.0. ZB  Although  the  Rationale  emphasizes  the  distinction,  the  LRM  confutes 
tasks  and  threads  of  control.  There  should  not  be  such  ambiguities.  XX11.S 
UR. 620 

9.0.ZC  There  should  be  a  unique  runtime  key  for  task  activations,  since  ther 
is  no  way  to  guarantee  such  with  current  language  facilities. 

UR. 124 


9.0. ZD  Low-level  synchronization  mechanisms  should  be  provided.  Channels 
should  be  primary,  not  rendezvous. 

LIR.197 

9.1  Task  Declarations  and  Task  Bodies 


9.1. A  Several  problems  are  raised  by  procedures  in  the  visible  part  of  a 
task : 

1)  When  initiating  a  task  a  procedure  call  can  only  be  achieved  once  the 
declarations  ■  *  the  corresponding  task  are  elaborated. 

2)  When  a  tar  erminates  (normally  or  abnormally)  there  may  still  be  ongoing 
procedure  cal... 

3)  The  interaction  of  procedures  and  accept  statements  is  complex. 

4)  Without  some  precautions  procedures  permit  access  to  locals  of  a  task 
and  raise  issues  similar  to  those  of  shared  variables.  XX9.4 

OPA.020 
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9.2  Task  Hierarchy  j  i 

9. 2.  A  Tasks  should  not  ba  nastad  within  procaduras  or  functions;  tacks 
should  only  ba  nastad  within  othar  tasks. 

BVR. 005(91. 5) 

9.3  Task  Initiation 

9. 3.  A  If  a  procaduro  In  tha  vlslbla  part  of  a  test  Is  called,  it  nay  ba 
abla  to  accass  variablas  whosa  daclaratlons  hava  not  yat  baan  alaboratad. 

Tha  semantics  of  tha  initiata  stataaant  ara  unclaar:  what  assuaptions  can  ba 
made  about  tha  state  of  an  inltiatad  task? 

LIR. 031  OPA .019 

9-. 3.B  Initiate  should  be  allowed  parameters. 

LIR. 278  LIR. 374 

9.3. C  It  would  often  be  useful  to  have  tasks  Initialized  at  elaboration 

(eg  semaphores). 

LIR.  279 

9.3.0  More  precise  definition  of  task  Initiation  Is  needed:  two  tasks 
cannot  be  made  active  simultaneously,  eg.  In  the  presence  of  Interdependent 
declaration  elaborations., 

C.IR. 572  | 

9.4  Normal  Termination  of  Tasks 

9. 4.  A  There  is  no  facility  for  synchronous  termination  of  embedded  tasks 
(particularly  when  such  tasks  are  encapsulated). 

LIR. 009 (S3 . 6)  LIR. 284 

9.4. B  There  ara  problems  of  logic  and  lmplementat.on  connected  with 

the  exit  of  scopes  containing  active  tasks. 

LIR. 022  LIR. 311 

9.4.0  Task  termination  is  ambiguous  and  in  fact  may  never  occur. 

EVR.005 (41.fi) 

9.4.0  Suggests  that  synchronous  termination  be  accomplished  by  predefining 
a  condition  Indicating  that  the  task's  containing  unit  wishes  to  terminate. 
LIR. 284 

9.5  Entry  Declarations  and  Accept  Statements 

9.5. A  Separating  entry  bodies  (like  procedure  bodies)  would  make  tasks 

easier  to  read  and  understand. 

LIR. 00903. 8) 

9.5.8  There  Is  no  syntactic  difference  between  an  entry  and  a  procedure 
invocation. 

P2R. 035(103)  P2R. 039(917) 


9.5. C  "Then*  or  "Begin*  is  preferred  to  "Do"  in  the  accept  statenent: 

Do  is  an  unnecessary  extra  keyword  with  incorrect  implications. 

LXR.332 

9.5. D  Entry  declarations  should  be  restricted  to  task  specifications.  An 

Interrupt  representation  specification  may  appear  in  the  task  body.  XX13.S.1 
LIU. 441 


9.S.E  Evan  null  bodies  of  Accepts  should  have  a  syntactic  terminator. 
UR. 442 


9.5. P  Entries  should  either  be  quite  distinct  from  procedures,  or  unified 

somehow,  it  is  currently  not  clear  whether  many  rules  apply  to  entries: 
overloading,  renaming,  address  specification,  placement  of  declaration  and 
bodv,  generic  subprograms.  Inline.  Do  the  rules  apply  differently  when  an 
entry  is  renamed  as  a  subprogram?  XX6.6  XX8.S  XX13.5  XX6.1  XX6.2  XX6.4 
LIR.444 

9.5. G  The  'identifier*  in  entry_declaration  is  presumably  the  entry  name: 

what  part  of  it  should  be  used  as~the  identifier? 

LIR.S54  LIR.S71 

9.5.  H  Why  is  initiation  of  a  task  prohibited  in  an  accept  body?  XX9.3 
LIR.572 

•i.S  Delay  Statements 

9. 6.  A  The  definition  should  indicate  that  a  delayed  task  will  be  queued  for 
scheduling  once  the  designated  delay  interval  has  passed. 

EVR. 002 (4207) 

9.6. B  In  addition  to  delaying  for  a  specific  real  time  interval,  there 

should  be  a  provision  for  a  delay  with  respect  to  another  task's 
execution  time. 

P2R. 032(403) 

9.6. C  The  semantics  of  the  delay  statement  are  context  dependent.  (See 

Select  statement) 

P2R. 036(400)  LIR.053 

9.6. D  There  should  be  some  way  to  wait  for  a  condition  (eg  resource 

available)  as  well  as  waiting  a  particular  length  of  time. 

LIR.375 

9.7  Selec  -  Statement 

9. 7.  A  There  is  no  provision  for  selectively  waiting  for  the  acceptance  of 
an  entry  call  (eg  timed-out  calls). 

LIR.009 (s3. 10)  LIR.359  LIR.360 


LIR.4S2 


9.7. B  The  language  should  guarantee  fairness  In  tha  salacc  statement: 

le  should  not  ba  possible  for  a  queued  antry  call  to  ba  permanently 
blocked  by  subsequent  antry  calls  sharing  the  sane  select  statement. 

EVR. 002  (#104)  P2R.  015  ( #07)  LIR.189 

9.7. C  The  language  should  either  (a)  restrict  the  variables  that  can 

appear  in  the  guards  of  a  select  statanent  to  those  that  cannot  change 
while  awaiting  the  entry  call,  or  (b)  guarantee  reevaluation  before 
selection  of  any  alternative  with  a  guard  that  nay  have  changed. 

EVR. 002(1209) 

9.7.0  There  should  be  conditional  entries  as  well  as  conditional  accepts.. 
EVR. 002(1216)  P2R. 039(115)  LIR.002 

9.7. E  The  language  should  guarantee  that  a  waiting  entry  call  will  always 

be  selected  in  preference  to  a  delay. 

EVR . 002 (4104) 

9.7. P  There  is  a  need  for  a  select  guard  that  is  true  only  If  all  others 

are  false,  when  Others  should  be  added  to  the  select  statement. 

LTR.025 

9 . 7. G  Select  should  clearly  be  specified  to  act  non-deterninistically,  as 
any  programs  depending  on  fairness  will  likely  be  implenentatlon-dependent. 
LIP. 089 

9.7. H  The  select  statement  is  too  complicated;  a  lower-level  nechanisn  is 

Preferred. 

.  *.231 

9.7.  The  present  rendezvous  concept  is  good:  timed-cut  entries  and 
sus^end/resume  would  hurt  effectiveness  and  uniformity. 

LiR.iss 

9.7. J  It  should  be  possible  to  have  exception  handlers  vith  scope 

co-extensive  with  one  select  alternative  to  catch  propagated  exceptions. 

LIS. 285 

9 . 7 .  K  There  should  be  entiy  call  timeouts.  The  details  of  a  correct 
implementation  are  discussed. 

LIR.319 

9.7. L  Entry  calls  should  be  allowed  in  Select  as  are  Accept'*  In  order  to 

express  a  nondeterminlstic  choice  between  consumption  and  production.  XX9.0 
LIR.397 

9.8  Task  Priorities 

9. 8.  A  The  language  should  guarantee  that  priorities  will  be  rigidly  enforcer 
during  scheduling. 

EVR. 002 (#210) 


9.8. B  Task  priority  should  be  assignable  at  initiation  time;  queue 

reordering  should  also  ba  possibla. 

EVR.001 (pll)  EVR .005(11.3)  P2R. 015(110)  P2R. 018(007)  P2R. 035(001) 

9.8. C  Scheduling  Is  vague  and  too  restrictive.  Implementation  dependency  1; 

encouraged  by  not  specifying  that  scheduling  Is  non-determlnistlc. 

LIR. 060  t.IR. 080 

9.8.0  The  semantics  of  priorities  are  unclear,  especially  In  the  presence  o 
monitor-type  tasks. 

LIR.081  UR.  083 

9.8.  E  Interrupt  handlers  should  have  priorities  but  should  not  be  subject  t< 
scheduling. 

UR.  146 


9.8.P  There  should  be  some  mechanism  for  specifying  the  mapping  between 
Ada's  priority  and  tasking  constructs  and  the  machine's. 

UR.  298 


9.8.G  Preemptive  scheduling  should  be  possible  in  any  implementation. 
UR.  352 


9.8.H  Tasks  should  be  able  to  set  their  children's  priorities,  but  why 
should  they  be  able  to  set  their  own? 

UR.  605 

9.9  Task  and  Entry  Attributes 

9.10  Abort  Statements 

9. 10.  A  Both  the  ABORT  statement  and  raising  FAILURE  are  extremely 
dangerous.  In  particular  asynchronous  termination  of  a  rendezvous  causes 
severe  problems  in  maintaining  the  consistency  of  internal  data. 

LIR.009 (33.7) 

9.10. B  The  Abort  statement  is  unnecessary. 

LIR.242 


9.10.C  Abort  should  not  take  a  name,  but  a  variable  as  an  argument;  it 
should  be  possible  to  abort  oneself  and  one's  parent  without  knowing  their 
names. 


LIR.363 


9.10.0  Tasking  exceptions  should  be  described  in  the  tasking  section,  not 
the  exception  section,  as  other  exceptions  are  described  with  their 
constructs,  or  at  least  cross-referenced  XX11.4 
UR. 555  LIR  .558 

9. 10. E  The  semantics  of  Abort  should  be  simply  those  of  raising  Failure  but 
ignoring  exception  handlers.  XX11.5 
LIR. 621 
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9.11  Signals  and  Semaphores 

9. 11.  A  The  built-in  (generic)  tasks  SIGNAL  and  SEMAPHORE  ara 
non-tradltlonal ,  difficult  to  uaa  and  unnecassary. 

LIR. 009 (»3 . 9) 

9. 11.  B  Making  semaphores  into  tasks  precludes  their  incorporation  into 
data  objects. 

LIR.060 

9.11. C  What  is  the  meaning  of  the  priority  of  a  semaphore? 

LIR.003 


9.11.0  What  is  the  meaning  of  priority  to  interrupts?  What  happens  to 
priority  when  a  high-priority  task  needs  the  services  of  a  low-priority 
task?  Discussion. 

LIR.427 

9.12  Example  of  Tasking 


10.  PROGRAM  STRUCTURE  AND  COMPILATION  ISSUES 


10.0. A  'Independent*  compilation  for  units  communicating  only  through 
parameter  lists  and  not  global  environment  should  be  defined  for  external 
units,  such  as  dynamically  loadable  units  and  foreign  language  units. 
LIR.130 


10.0.B  The  separate  compilation  feature  is  unnecessary.  Source  inclusion 
or  support  utilities  should  deal  with  separate  compilation. 

LIR.144  LIR.S84 

10.0.C  What  units  ara  actually  loaded?  What  is  the  minimum  one  can 

expect  of  the  library  and  loader  in  terms  of  not  loading  unused  units?  What 
is  the  unit  of  loading?  Subprograms,  modules,  compilation  units? 

LIR.321 

10.1  Compilation  Units 

10.1.  A  The  present  system  has  both  too  many  surprising  consequences,  and 
precludes  too  many  useful  optimizations.  A  simpler  system  wtuid  be  quite 
adequate. 

EVR  .00  "MU. 3)  P2R.005  ( 105)  P2R.005  ( 108)  P2R.006(«0S)  P2R. 030(101) 

P2R.037 (#07)  OCR. 003  LIR.128 

10.1. B  The  language  allows  separate  compilation  of  nested  entities 

(modules,  procedures,  tasks);  for  the  programmer,  it  will  be  very  difficult 
to  know  the  environment  of  such  a  separately  compiled  entity. 

P2R. 014(407) 
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10.1. C  The  physical  Interface  contains  too  ouch  information.  In  particular 

the  private  part  should  specify  the  representation  of  any  visible  private 
types. 

pep. 003 

10. 1.  D  Visibility  restrictions  are  overly  restricted  in  separate 
compilations. 

LIR. 139 

10.1. E  Stubs  for  subunits  can  sometimes  be  ambiguous.  XX10.2 

UR.  118 

10.1. P  The  system  of  separate  compilation  incorporates  too  much  information 

about  what  units  will  be  compiled  together  into  the  text  of  the  program. 

UR.  120 

10.1. G  It  can  be  Impossible  to  distinguish  identically  named  subunits 

without  blacking  their  vision  of  a  common  enclosing  unit. 

UR. 140 

10.1. H  What  exactly  IS  a  program  library? 

UR.  556 

10.1.1  Syntax  of  compllation_unit  should  presumably  be 

Tvisibility  restriction  (Separate) ]  unit  body  {cf.  10-5  line  1). 

UR.  573 

10.1. J  There  are  cases  where  separate  compilation  seems  unnecessarily 

illegal.  (Example) 

UR.  622 

10.2  Subunits  of  Compilation  Units 

10. 2.  A  Selected  components  of  compilation  units  should  be  specifiable  in 
Restricted  statements,  eg  if  Main  has  subunit  A,  permit  Restricted(Maln.A) . 
OPA.016 

10.2.8  The  enclosing  unit  of  a  subunit  should  be  explicitly  specified  in  the 
compilation  unit  header — it  is  otherwise  ambiguous  for  reader  and  compiler. 
XX8.3 

UR.  128  UR.  241  LIR. 436'  UR. 445  UR. 574 

UR.  597  UR.  604  UR. 609  LIR. 611 

10. 2.  C  Separately  compiled  overloaded  subprograms  within  the  same 
enclosing  unit  should  not  be  allowed.  XX10.1 

LIR .304 

10. 2.  D  Separation  of  bodies  from  specification  should  not  ba  restricted 
to  the  outermost  scope.  XX7.0 

LIR. 449 

10. 2.  E  What  IS  a  subunit? 

LIR. 574 


i 


19.3  Order  of  Compilation 


19. 3.  A  The  strategy  for  ordering  separate  compilation!  doas  not  work  In 
tha  prasenca  of  separate  generic  units,  inline  subprograms,  raprasantatlon 
specifications,  and  certain  raqulrenants  conearning  calls  to  procaduras 
with  side  affects. 

P2R. 095(101)  LIR. 004  COM. 992  OCR. 993 

19.4  Program  Library 

19. 4.  A  The  program  library  file  should  not  be  updated  by  all  compilations 
as  this  may  compromise  Its  integrity. 

LIR. 120 

19.5  Elaboration  of  Compilation  Units 

19.6  Program  Optimization 

19. 6.  A  It  is  unclear  that  some  optimizations  concerning  functions  and 
variables  with  ‘abnormal*  behavior  can  be  performed  by  the  translator. 

POS . 003 (p91 )  OCR. 993 

19. 6.  B  “i,,™  should  be  explicit  conditional  compilation,  using  pragmas. 
UR. 936 


19. 6. C  The  programmer  should  be  able  to  ask  for  many  implementation 

choices  and  optimizations  explicitly:  omission  of  GC;  static  allocation;  use 
of  global  flow  analysis;  suppression  of  runtime  checks.  XX2.7 
LIR. 410 


19.6.0  Discussion  of  optimization  should  be  left  to  the  Rationale. 
LIR. 575 


11.  EXCEPTIONS 


11. 9.  A  Manual  does  not  make  clear  what  exception  gets  raised  for  soma  cases 
of  constraint  violation. 

LIR. 908(s3. 3) 

11.9.8  Underflow  should  not  be  an  exception. 

EVR. 005 (12.1)  LIR. 366 

11. 9.  C  There  is  no  way  to  handle  user  exceptions  propagated  beyond  the  scope 
of  their  definition  (’Unhandled*  exception) .  Should  Others  handle  them? 

LIR. 048  LIR. 539 

11.0.0  There  should  be  no  exception  facility  as  it  introduces  too  great  an 
overhead. 

LIR. 244 
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11.0. E  What  happens  whan  an  exception  propagates  beyond  its  scopa? 

Making  axcaption  definitions  global  is  suggested. 

LIB. 240 

11.0.F  Explicitly  ralsad  axcaptions  should  laava  variables'  valuas  wall 
defined. 

LIB. 367 

11.1  Exception  Declarations 

11.1.  A  No  valua  arror  is  ill  foundad. 

OPA.015 

11.1.8  No  valua  arror  is  too  axpanslva  to  implement. 

LIR.034 

11.1. C  No  value_error  from  a  function  should  ba  ralsad  in  tha  caller's 

environment.  ~ 

LIB. 088 

11.1.0  It  is  not  claar  whan  and  whara  which  pradafinad  axcaptions  are 
raised. 

LIB. 557 

11.2  Exception  Handlers 

11. 2.  A  The  language  should  guarantee  that  actual  Out  parameters  will  not  ba 
assigned  If  the  routine  is  exited  abnormally  (i.e.,  by  exception).  XX6.3 
EVR . 002  ( H02)  P2R.  043  ( #13) 

11.2.8  There  is  a  need  for  exceptions  that  will  not  ba  handled  by  Whan 
Others. 

LIR.016 

11. 2.  C  Exception  handlers  should  have  access  to  tha  environment  at  the  point 
of  an  exception  for  tasting  and  debugging. 

LIR.057 


11. 2.  D  It  should  not  be  possible  to  access/raf arenca  unelaborated  or 
incompletely  elaborated  declarations  from  within  an  exception  handler. 

EVR . 002 ( #213)  DCB.005  OPA.012 

11. 2.  E  It  should  ba  possible  to  specify  explicitly  in  the  exception  handler 
whether  terminative  or  resumptive  semantics  apply  to  tha  particular  handler. 
EVR. 005(115.0) 

11. 2.  F  There  should  be  some  way  to  identify  an  exception  caught  by 
"Others*  for  debugging  and  error  messages. 

LIR.184  LIR.399 

11. 2.  G  It  should  ba  possible  to  return  and  continue  after  an  exception. 
LIR.465 


XI. 2. H  exception*  should  pass  parameters,  eg  Ass*rt{35)  x>0».  XXS.9 

LIR. 466 

XI. 2. I  If  an  exception  propagate*  out  of  a  scop*  and  back  in.  Is  it 
handled  by  the  naaed  handler  or  Others?  Presuaably  the  named  handler. 

Cxanpl*  given. 

LIR. 526 

11.3  Raise  Statements 

11.4  Exceptions  Raised  During  Tasking 

11. 4.  A  Propagation  of  Tasking  error  compounds  the  problems  of  asynchronous 
termination,  especially  with  regard  to  procedures  in  the  visible  part  of  task; 
LIR. 009 (s3. 7) 

11.5  Raising  an  Exception  In  Another  Task 

11. 5.  A  The  asynchronous  exception  Tasking  error  may  be  raised  on  the 
accepting  task  during  a  rendezvous.  This  disruption  causes  problems  for 
tasks  that  require  Indivisible  updates  of  their  data  structures  In  order  to 
maintain  consistency. 

LIR. 003 


11. 5. B  The  semantics  of  raising  the  failure  exception  In  another  task 
are  unclear  and  sometimes  counter-intuitive. 

LIR. 119 


11. 5.  C  The  semantics  of  the  failure  exception  are  complicated  in  the  presenc 
of  multiple  threads  of  control  corresponding  to  a  task:  exception  propagation 
Is  dangerous.  The  example  of  Rational*  12.4.1  Is  flawed  and  demonstrates  the 
dangers.  The  Failure  exception  should  only  take  effect  when  the  thread  of 
control  executes  Inside  the  task  or  when  It  returns  to  it.  The  question 
remains  as  to  whether  a  thread  of  control  waiting'  In  an  entry  Is  executing 
Inside  or  outside  the  task.  XX9.0 

LIR. 620 

11.6  Suppressing  Exception? 

11. 4. A  The  language  should  restrict  the  consequences  when  a  suppressed 
exception  occurs. 

EVR. 002(0212) 

11. 6.  B  The  semantics  of  suppressing  the  ASSERT  ERROR  exception  should  be 
specified. 

LIR. 019 


12.  GENERIC  PROGRAM  UNITS 


12.0.  A  There  should  bs  task  generic  parameters.  for  example,  task  antrlss 
should  bs  allowed  as  generic  paraastars. 

P2R. 039(108)  LIR. 015 

12.0.B  Thara  Is  a  naad  for  a  spacif Icatlon  and  assartlon  language  for 
generics.  It  Is  not  claar  at  this  tiaa  what  the  problaas  will  ba.  Thara  are 
strong  rasarvations  about  a  language  that  allows  thing  to  look  the  saaa  but 
have  different  meanings. 

P2R. 043(*0S) 

12.0.C  The  generic  facility  does  not  provide  true  paraneterized  types  nor 
can  it  express  type  interrelations  and  properties  (eg  T  is  a  discrete  type) . 
How  can  a  record  field  be  guaranteed  to  exist?:  the  type  cannot  be  restricted 
nor  can  the  field  naae  be  a  generic  parameter.  Consider  also  the  Interaction 
with  separate  compilation. 

LIR. 070  LIR. 198  LIR. 388 

12.0.D  Overloaded  generic  subprograms  cannot  be  disambiguated:  prohibit 
them.  XX4.1.2  XX6.fi 
LIR. 527 

12.0.E  A  generic  subprogram  can  have  the  same  signature  as  a  non-generic 
subprogram  but  be  distinguishable.  Can  one  overload  the  other?  XX6.6 
LIR. 528 

12.0.P  Overloading  of  generic  subprograms  by  generic  clause  is  not 
allowed.  Put  it  could  be.  XX6.6 
LIR. 529 

12.0.G  Generic  functional  arguments  may  require  implementation  techniques 
identical  to  those  required  for  functional  arguments.  XX6.0 
LIR. 523 

12.0.H  Generic  parameters  should  be  allowed  to  be  generic  subprograms. 

LIR. 623 

12.0.1  All  compilation  and  error-checking  of  generic  subprograms  should 
occur  at  instantiation  time. 

LIR. 207 


12.0.J  A  general  macro  facility  is  desired. 

LIR. 211 

12.1  Generic  Clauses 

12.1. A  The  concept  of  a  "designator"  as  an  "attribute  of  a  type"  is  vague 
and  confusing. 

LIR. 136 


12.1.B  The  syntax  of  Subprogram  specification  as  a  Generic  Parameter  allows  i 
Generic  clause.  Forbid  this  eitKer  in  the  syntax  or  the  semantics. 

LIR. 215~  LIR. 287  LIR. 473 
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12. 1 . C  What  ara  tha  exact  semantics  of  generic  Out  and  In  out  parameters?: 
suggests  forbidding  than. 

LIR.288 

12.1.0  Tha  attrlbuta  'Size  of  a  ganartc  type  parameter  should  ba 
available  In  tha  generic  body. 

LIR.290 

12.1. E  Allow  antrias  as  ganarie  paranatars. 

UR.  291 

12.1. F  Ganarie  units  and  antrias  should  bo  allowed  as  ganarie  paranatars. 

Visibility  for  tha  generic  body  should  ba  defined  by  tha  point  of 
Instantiation.  Extensive  discussion  of  Interdependent  generic  tastes. 

UR.  398 


12.1. G  Record  conponont  nanes  should  be  allowed  as  generic  paranatars. 

UR. 419  UR. 474 

12. 1 . H  There  should  be  a  way  to  indicate  that  the  parameter  declarations 
among  tha  generic  parameters  are  commutative.  (??) 

UR .  459 


12.1.1  Exceptions  and  packages  should  ba  allowed  as  generic  paranatars. 
UR. 474 

12.2  Generic  Instantiation 

12. 2.  A  Implicit  Instantiation  of  generic  subprograms  is  needed.  Implicit 
instantiation  of  other  ganarie  definitions  is  not  needed. 

EVR. 082(1301)  EVR. 0031*3.4) 

12. 2.  B  Ada  relies  heavily  on  generics.  In  particular,  they  are  the  means 
for  realizing  parameterized  types.  Procedures  and  functions  that  take 
parameterized  types  must  also  be  generic.  Thus  the  compiler  must  be  able  to 
recognize  when  generic  procedure  instantiations  may  share  code.  Can  it? 
EVR. 003 (P02) 

12. 2.0  There  is  a  problem  with  instantiating  a  generic  with  a  type  that  Is 
an  unconstrained  array  type. 

UR. 028 


12. 2. E  "New  name"  should  presumably  read  "new  designator*. 
UR. 034 


12. 2. F  The  syntax  of  generic  association  should  allow  'designator  Is”,  but 
formal  parameter  restricts  it- to  identifiers. 

UR.  57* 


12. 2. G  Generic  parameters  used  in  static-evaluation  contexts  in  the  body 
should  not  be  required  to  be  static. 

UR. 289 
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12. 2. H  The  syntax  of  generic  definition  and  instantiation  violates  the 
principle  that  specifications  should  parallel  uses.  Syntax  suggested. 
UR.  191 

12.3  Example  of  a  Generic  Package 


13.  REPRESENTATION  SPECIFICATIONS  AND  IMPLEMENTATION  DEPENDENT 
FEATURES 

13.0. A  There  should  be  an  escape  mec‘;*<nism  that  will  permit  the  user  to 
specify  the  storage  management  algorithm  toe  polnter/heap  storage.  XX3.8 
EVR. 0020304) 

13.0.B  The  programmer  might  be  restrained  It  acceptable  space  and  access 
efficiency  were  needed,  for  example  by  prohibiting  arrays  with  dynamic  bounds 
or  minimizing  shared  variables.  XX3.S 
EVR. 001 (pi  3) 

13.0.C  Programs  using  pointers  cannot  be  guaranteed  to  be  free  of  garbage 
collector  overhead.  XX3.8 
P2R. 022(401)  UR. 24.1  UR. 250 

13.0.D  Non-stack  storage  allocation  is  needed  to  implement  parallelism  and 
dynamic  storage:  where,  then,  is  local  storage  for  a  task  allocated?  In  a 
single  address  space  model,  the  new  process  must  be  allocated  storage  of 
some  fixed  size  at  initiation.  Fixup  action  must  be  taken  on  overflow,  or  a 
probe  is  needed  before  growing  the  stack.  Both  are  too  inefficient  for 
embedded  computer  applications.  XX9.0 
P2R.  027(003) 

13. 0. E  There  are  no  facilities  for  program  overlays. 

UR. 001 


13.0.F  Make  it  clear  that  *  length  specification  fer  a  collection 
Inhibits  garbage  collection  (and  hence  permits  user  definition  of 
Allocate  and  Free  as  shown  in  Washington  April  meeting).  XX3.8 
OPA.002 

13.0.C  Representation  change  is  prohibited  for  derived  record  and 
enumeration  types  with  user  attributes  but  not  for  similar  array  types. 
UR.  100 


13.0.H  Representations  should  be  a  part  of  type  declarations  (not  separate) 
and  have  a  more  compact  form.  XX6.1 
UR.  157  UR.  249  UR.  276 

13.0.1  Is  bit  0  the  low-order  or  the  high-order  bit?  XXA 
UR. 157  UR.  351 


13. 0. J  The  For/Us*  construct  Is  overloaded. 

LIR.247  LIR. 249 

13.0.K  More  of  the  attributes  of  a  type  should  be  Incorporated  Into 
declarations  rather  than  representations.  XX3.0 
LIR. 249 

13.0. L  There  should  be  a  representation  specification  for  fixed-point 

numbers  defining  the  value  of  the  most  significant  digit  and  precise  layout. 
(Some  suggest  making  this  part  of  the  type  definition  itself.)  XX3.S.5 
LIR. 306  LIR. 350  LIR. 391  LIR. 412  LIR. 413 

LIR. 423 


13.0.M  Lack  of  Inheritance  of  representations  by  derived  types  seen  as 
possibly  burdensome. 

LIR. 462 

13.0.N  Some  sort  of  representation  specification  Is  desired  for  arrays. 
LIR. 463 

13.1  Packing  Specifications 

13.2  Length  Specifications 

13.2.  A  The  length  specification  for  an  access  type  should  not  be  required 

to  be  static. 

LIR. 429 

13. 2. 8  What  Is  the  type  of  the  static  expression? 

LIR. 577 

13.3  Enumeration  Type  Representations 

13. 3.  A  It  should  be  possible  to  specify  contiguous  representations  of  runs 
of  enumerals  without  writing  them  all  -ut:  suggests  that  unmentioned 
enumerals  received  the  representation  of  the  preceding  enumeral  plus  one. 
LIR. 286 

13. 3.  B  The  current  syntax  for  enumeral  representation  Is  not  transparent 
In  meaning.  The  requirement  that  a  representation  aggregate  be  named  when 
there  Is  but  a  single  enumeral  Is  a  disturbing  Irregularity  in  the  syntax. 
Perhaps  the  syntax  of  aggregates  is  to  blame.  XX3.6.2  XX4.6 

LIR. 531 

13.4  Record  Type  Representations 

13. 4.  A  The  syntax  is  considered  clumsy  and  redundant. 

LIR. 064 

13. 4. 8  Alignment  clause  cannot  specify,  e.g.,  1  mod  8,  but  only  0  mod  8. 
LIR. 093 
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13. 4.  C  “At*  is  a  poor  keyword  hers. 

UR.  093 

13.1  Address  Sped f Ications 

13. 5.  A  Can  two  variables  be  given  the  sane  address?  Clarify  manual. 

LIR.352 

13. 5.  B  for... Use  at  is  too  static  and  one-memory  oriented.  XXA 
UR.  396 

13.5.1  Interrupts 

13. 5.1.  A  Interrupts  should  not  be  queued. 

UR. 146 

13.5.1.8  Interrupts  should  be  ‘masked  out*  Inside  their  own  handlers. 

I.IR. 146 

13.5.1. C  What  happens  when  two  entries  are  attached  to  the  s.>*.e 
interrupt? 

UR.  239 

13.5.1. D  How  does  one  guarantee  immediate  servicing  of  interrupts? 

UR. 239 

13.5.1. E  There  is  apparently  a  problem  in  Implementing  Ada  interrupts  on  the 
UYK-20. 

UR  .180 

13.6  Change  of  Representations 

13.7  Configuration  and  machine  Dependent  Constants 

13. 7.  A  A  floating-point  real-time  clock  is  impractical;  moreover,  the 
clock  should  measure  time  of  day  rather  than  time  since  initiation.  There 
is  an  ISO  standard  on  date  and  time  which  should  be  consulted. 

EVR .  002  (1208)  P2R. 002(103)  P2R. 025  ( 106)  DCR.0P5  UR. 301 

UR.  393  UR.  422 

13. 7.  B  The  notion  of  task  cumulative  processing  time  ('Clock)  forces 
inefficiencies;  System'Clock,  however,  is  useful. 

OPA.009  DCR.006 

13. 7.  c  There  should  be  an  implementation-independent  fixed-point  clock. 

UR. 415 

13. 7.  D  What  manner  of  beast  are  System  and  Option?  They  are  predefined 
names,  but  not  reserved  words  or  package  names.  Are  they  object  names?  UR 
suggests  they  be  predefined  internal  packages;  their  attributes  would  thus 
be  selected  by  dot  notation.  XXA  XXC 

UR.  471  UR.  492 


13.8  Machine  Code  Insertion* 


13. 8.  A  Thsrs  should  not  bs  any  special  mechanism  unique  to  Machine 
and/or  assembly  language. 

EVR. 802(1211)  P2R. 014(406)  P2R. 022(406)  P2R. 828(t02)  P2R. 042(401) 

13. 8.  B  This  section  Is  too  vaque. 

LIR.034 

13. 8.  C  Assembler  Insertions  should  have  conventional  syntax. 

UR. 424 

13.9  Interface  to  Other  Languages 

13.9.  A  The  same  mechanism  should  be  used  for  assembly  languaqe 

and  machine  code  interfaces  as  Is  used  for  Interfacing  other  programming 
languages. 

EVR. 002(4211)  P2R. 008(401)  P2R. 044(407) 

13.9.8  It  Is  not  specified  how  to  Invoke  a  procedure  from  another  language. 
P2R. 037  (40(5) 

13. 9.  C  There  are  some  problems  with  the  foreign  code  Interface  for 
Fortran,  e.g.  matrix  representation,  slice  parameters,  functions  as 
parameters,  and  variable  length  parameter  lists. 

UR. 014 


13. 9.  D  How  are  Ada  programs  called  by  programs  in  other  languages? 

UR. 157 

13. 9.  E  It  Is  suggested  that  the  Ada  interface  conventions  for  a  given 
machine  become  the  standard  conventions  for  the  other  languages  on  that 
machine.  All  machine  and  QS  formats  should  be  defined  as- Ada  data 
structures.  Ada  Should  be  the  standard  intermediate  languaqe. 

UR. 296 

13. 9.  F  There  should  be  a  standard  (unsafe)  way  of  building  an  Ada  array 
from  a  block  of  storage  passed  into  an  Ada  routine  from  a  non-Ada  routine. 

LIR.387 

13. 9.  G  More  support  is  needed  for  Interface  to  other  languages.  Perhaps 
machine-dependent  code  should  be  isolated  In  a  special  module  as  proposed  In 
Euclid. 

UR.  578 

13.10  Unsafe  Type  Conversion 

13. 10.  A  Reinterpreting  the  type  of  an  object  without  real  conversion  Is 
desired. 

UR .  0(5  2 

13.10. B  The  name  Unsafe  programming  Is  too  strong. 

UR.  309  UR .  45 1  “ 
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13. 10.  C  The  applicability  of  Unsafe  conversion  to  I/O  is  not  made  clear. 
LIR. 349 

13.10. D  What  exactly  does  Unsafe_Conversion  do?  When  it  is  imposing  a 
type  on  previously  untyped  data,- it  should  check  for  Range  Error. 

LIR. 451 


14.  INPUT-OUTPUT 


14.0. A  For  an  I/O  handler,  multiple  instantiations  and  numerous  names 
are  required  to  use  files  of  all  types.  This  is  extremely  cumbersome  if 
many  types  ate  present. 

P2R. 039(407) 

14.0.B  The  untyped  binary  I/O  on  which  typed  binary  I/O  is  built  should  be 
visible  to  users  and  standard  across  implementations,  since  it  must  of 
necessity  exist  under  Input  Output. 

LIR .107 


14.0.C  The  I/O  model  is  at  too  high  a  level,  too  sequentially  oriented 
and  overly  attaches  to  the  idea  of  one  data  type  par  file. 

LIR. 046 

14.0.0  There  should  be  a  high-level  model  of  real-time  data  stream  I/O. 
LIR. 327 


14.0.E  The  I/O  package  should  not  be  addressed  in  the  LRM. 

LIR. 371 

14.0.F  There  should  be  some  standard  way  to  time-out  from  I/O. 

LIR.37S 

14.1  General  User  Level  Input-Output 

14.1.  A  The  departure  from  conventional  I/O  techniques  may  lead  to 
nonstandard  I/O  techniques  between  similar  systems.  In  particular 
'conventional*  read,  write,  and  format  statements  are  missing. 

EVR. 005(45.0)  LIR. 238 

14.1.8  Objects  of  mixed  types  should  be  allowed  to  coexist  on  files. 
LIR. 107  LIR. 327 

14.1. C  A  standard  package  Implementing  Fortran-like  formats  should  be 

defined. 

LIR. 299 


14.1.1  Files 


-  it,  - 

14. 1.1. A  There  should  be  a  function  for  determining  whether  a  filename 
corrasponds  to  an  existing  and  accessible  flla. 

HR.  421 


14.1.1. B  Renaming  of  filas  Is  missing.  Thara  is  no  way  provldad  to  wrlta 
and  and  of  flla  mark  or  change  the  valid  length  of  a  file.  It  should  not  ba 
necessary  to  open  a  flla  to  dalata  it. 

CIR. 296 

14.1.2  Rile  Processing 

14. 1.2.  A  The  names  Read  and  Write  should  ba  exchanged  with  Cat  and  Put 
for  naturalness  and  Pascal  compatibility.  XX14.3 

HR.  372  t.IR.395 

14.1.2,8  End  of  file  should  be  a  predicate,  not  an  exception.  XXC 
HR .  439 


14.1.2. C  Read  without  advancing  the  file  pointer  is  missing. 

HR.  206 

14  2  Specification  of  the  Package  INPUT  OUTPUT 

14. 2.  A  It  is  worthwhile  to  treat  I/O  devices  as  uniformly  as  possible. 

This  raises  many  subtleties  of  treating  I/O  devices  as  files. 

HR. 007  HR.  01 3 

14.2.8  Array  I/O  should  be  defined. 

HR.  106  HR.  327 

14. 2.  C  Some  method  of  forcing  buffers  out  (i.e.  draining,  flushing)  should 
be  defined. 

HR .  109 

14.2.0  The  exceptions  in  different  instantiations  of  the  generic  package 
lnput_0utput  cannot  be  distinguished.  The  package  should  have  functions 
which- return  information  as  to  what  caused  the  exception.  XX11.1  XX12.2 

LIR. 475 


14. 2.  E  Delete  is  missing  (cf.  14.1.1). 

HR. 217 

14.3  Text  Input-Output 

14. 3.  A  Imbedded  carriage  control  characters  would  be  nonstandard  across 
systems,  and  cause  confusion  in  Ada  I/O;  thus,  a  machine  Independent 
mechanism  should  exist  for  carriage  control. 

LIR. 108 


14.3.8  Can  Ada  I/O  support  a  text  editor  efficiently?  More  support  Is 
needed  for  terminal  text  I/O. 

LIR. 579 
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14. 3. C  There  should  be  ism  standard  tett  I/O  for  structured  types 
(records) . 
till.  379 


14.3.0  Slaulatsd  I/O  (Fortran  Encode/Decode)  Into  strings  is  desired:  Get 
and  Put  should  be  overloaded  on  the  Pile  paraaeter. 

LIB. 1*2 


14. 3. t  Input  and  output  of  test  lines  are  desired. 

LIB. 183 

14.3.1  Standard  Input  and  Output  Files 

14.3.2  Layout 

14. 3. 2.  A  ’Tab*  is  used  for  *HT*  despite  Appendix  C.  XXC 
LIB. 1*3 

14.3.2.8  The  effect  of  Tab  is  nonstandard  (should  be  next  multiple  of 
eight  plus  one) . 

LIR.1S5  LIR.580 

14.3.2. C  Do  control  characters  actually  appear  in  flies,  or  do  they  Just 
Indicate  effects?  In  particular,  the  distinction  between  Newline  and  CR  & 
LF  is  unclear.  If  the  characters  appear  in  files,  how  does  the  file  system 
work  on  record-oriented  systems? 

LIR.B98 


14.3.2.0  Tab  stops  should  be  user-specifiable.  Outputting. a  Tab  should 
insert  the  appropriate  number  of  spaces. 

LIB. 181 

14.3.3  Input-Output  of  Characters  and  Strings 

14. 3. 3. A  LRM  confuses  issue  of  quotes  within  strings. 

LIB. 103 

14.3.4  Input-Output  for  Other  Types 

14.3.5  Input-Output  for  Numeric  Types 

14. 3. 5. A  Beal  number  input  syntax  should  be  more  liberal. 

LIR.110 


14. 3. 5. A  The  Get  function  rounds  inputs  to  Float'Oigits  rather  than  to 
the  full  precision  of  the  object  gotten. 

LIR.105 


14.3.S.B  Po  positive  numbers  print  with  initial  *+•,  blank,  or  digit? 
LIB. 099 

14.3.6  Input-Output  for  Boolean 
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14.3.7  Input-Output  for  Enumeration  Typos 

14. 3. 7. A  The  case  of  enumeration  types’  output  should  ba  spaelflabla. 

LIB. 099 

14.4  Spaclf leatlon  of  tha  Package  TEXT  10 

14. 4. A  An  expression  on  14-11  la  misting  naadad  qualifications. 

LIR.105 

14.4.8  Tab  stops  ara  poorly  defined  and  probably  non-standard. 

LIR.125 

14.5  Examp?'  of  Text  Input-Output 

14.5  Low  Laval  Input-Output 

A  Predefined  Language  Attributes 

A. A  The  word  "machine*  la  used  where  "Implementation"  Is  meant. 

LXR.105 

A.B  The  definition  of  ASCII  as  an  enumeration  type  is  circular. 

LIR.063 

A.C  T' Rep  Is  Incompatible  with  Put  In  that  It  does  not  taka  width  and  fra- 

arguments. 

LIR.099 

A.D  There  should  be  a  useful  'Address  fer  data  not  word-aligned. 

LIR.2B0  LIR.381 

A. E  'Size  should  apply  to  program  units.  This  is  useful  for  memory 

allocation,  swap  control,  and  overlays. 

LIR.2S3 

A.F  The  'Address  for  non-contiguous  packages  (eg  pure  and  impure  parts) 

is  not  well  defined  and  not  entirely  useful. 

LIR.264 

A.G  What  are  the  types  of  'Delta,  'Small,  System’Min  Int,  and 

System 'Max  Int?  XX3.S.5  XX13.7  “ 

LIR.330  ~  LIR.470  LIR.492 

A. H  What  is  the  meaning  of  'Address  in  segmented  and  multiprocessor 

architectures? 

LIR.331  LIR.395 

A. I  The  attributes  'Size,  etc.  should  be  defined  in  terms  of  digits,  not 

bits,  and  the  base  of  the  machine  should  be  a  system  attribute.  ’Small  and 
'Large  should  also  be  defined  in  a  radix-independent  way.  XX13.2 
LIR.331 
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A.j  Bit  positions  should  be  l-ofigin,  not  0-origln.  XX13.4 

LIH.331 

A.K  Pag*  sis*  should  bs  a  system  attribute.  i  , 

LIR. 370 

A.  L  ’Bits  and  'Radix  should  only  bs  defined  for  floating  point  types. 

'Bits  should  be  renaaed  'Mantissa;  abolish  'La  and  'Basil.  XX3.S.S 
LIR. 379 

A.M  Abolish  'Access_Size— the  meaning  of  'Size  should  be  unifora. 

Introduce,  eg,  'Denoted- Si ze  if  desired. 

LIR. 380 

A.M  'Size  should  be  clearly  defined  to  be  the  naxiaua  size  of  an  object 

of  the  type.  (Consider  records  with  variants,  etc.) 

LIR.381 

A.O  There  should  be  a.  predefined  attribute  of  any  type  converting  to  a 

fixed  length  array  of  character. 

LIR.420 

A.p  The  Identifier  Priority  is  both  an  attribute  naae  and  a  type.  This 

is  legal  but  confusing.  Change  the  type  to  Task  Priority. 

LIR. 472 

A.O  Why  are  there  no  Systea'Min  Float  and  ‘Max  Float?  XX3.S.S 

LIR. 60S  ~  ~  i 


A.R  ’Rep  should  allow  more  than  three  digits  of  exponent  when  necessary. 

LIR.179  . 


Predefined  Language  Pragmas 


B.A  When  Pragma  Optimize  is  not  used,  are  no  optimizations  performed? 

How  does  one  optimize  only  part  of  a  module?  What  is  the  default  state  of 
Optimize? 

LIR.533 


B.B  Define  the  effect  of  the  pragmas  Page,  List,  and  Include  on  listings 

more  precisely. 

LIR.534  LIR.535  LIR. 536 


Predefined  Language  Environment 


C.A  Attributes  of  record  components  should  not  be  applicable  to 

discriminants,  since  they  need  not  be  present. 

LIR. 088 (s4. 8) 


C.B 

LIR. 103 


,  *,  1,  and  #  lack  enumeration  literals. 


The  characters  % 


/ 
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C.C  Thar*  should  b*  a  predefined  typa  Tim*_lnterval  distinct  from  Tim 

with  only  approprlata  operations  on  aach  (eg  no  Tlme+Tlme) . 

LIR. 3(1 


C.D  Exponentiation  and  Mod  should  b*  defined  for  more  combinations  of 

types  to  encoutage  uniformity.  XX3.S 
LIR. 333 

C.E  Common  mathematical  functions  (square  root,  sine,  ate.)  should  b# 

predefined. 

LIR. 392 


D  Glossary 

D.A  Suggests  some  addit  onr  In  the  area  of  access  variables.  XX3.8  XX4.7 

LIR. 477 


E  Syntax  Summary 

E.A  There  are  too  many  '  indetermlnlsms*  in  the  current  syntax. 

LIR. 293 

E.B  Syntax  summary  is  incomplete. 

LIR. 295 


Index 

Index. A  The  index  is  Inadequate. 

LIR. 115 

Index. B  The  index  omits  Program  Units  (1.7)  and  Declare  (6.7)  and  indexes 
Initial  value  Incorrectly. 

LIR. 464 

Index. C  Some  grammar  non-terminals  are  not  In  the  index.  The  standard 

identifiers  (First,  Environment,  Integer)  should  certainly  be  included  also. 
LIR. 537 


Z  General  questions  of  syntactic  style 


Z.A  The  syntax  has  too  many  noise  words  and  too  much  redundancy  in 

general.  On  the  other  hand,  some  keywords  are  overloaded  with  quit* 
distinct  meanings  in  different  contexts,  e.g.  else,  exception,-  for,  new 
others,  restricted,  range,  is.... 

LIR. 041  LIR. 597  LIR. 601  LIR. 603  LIR. 607 

LTR.629 


Z.B  Syntax  is  too  verbose  and  keywords  are  too  long. 

LIR. 047  LIR. 078 


Z.C 

LIR. 052 


The  permissible  nesting  of  subprograms,  generics,  and  modules  is  vagu- 
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Z.D  Every  type  o ff  "end"  should  be  qualified  by  the  block  nan*  or  type.  A 

least,  the  meaning  and  optlonallty  of  Identifiers  after  End's  should  be 
uniform.  Currently  they  are  not:  End  name  for  task  bodies,  but  End  Case  for 
cases,  and  just  End  for  Begins.  XXS.6  XX6.4  XX7.1 
LIR.894  LIR.217  LZR.5S3 

Z.E  The  syntax  is  far  too  permissive:  semantic  distinctions  are  blurred  at 

ambiguities  often  engendered.  XX7.1  XXS.5  XX2.6.2  XX3.S.5  XX3.6  XX10.2  XX5.2 
XXfi.  2 

LIR.162  LIP .628 

Z.F  Semicolons  should  be  used  for  statement  termination  only;  commas 

should  be  used  to  separate  Items  in  a  series  (eg  parameters). 

LIR.20S  LIR.250 

Z.G  Semicolon  should  be  a  statement  separator,  not  a  terminator:  consider 

especially,  the  semicolons  after  end's  of  different  kinds. 

LIR.443 

Z.B  In  several  places,  the  syntax  (name. 1  designator  Is  used  where  it  seem: 

new  nonterminal,  subprogram_designation,  defined  as  name  I 

(name .) character  string,  would  be  more  appropriate,  cf.  renaming  declaration 
generic  parameter,  and  generic  association.  XX4.1  XX8.S  XX12.1  XX12.2 
LIR.filS- 


Z.I  The  "upper-level*  syntax  (unit  headers)  Is  ad  hoc  and  poorly  structur- 

For  Instance,  generic  names  appear  at  the  wrong  place.  The  whole  upper  level 
should  be  redesigned  starting  from  the  abstract  syntax.  XX12.1  XX8.3 
LIR.633 


Z.J  Empty  fields  (not  "null;")  are  allowed  In  some  surprising  places. 

Usually,  the  metasyntax  (...)  Is  used  where  "one  or  more*  would  seem  more 
appropriate.  XX3.7  XX5.0  XX5.5  XX6.7  XX9.7 
LIR.202  LIP. 218 


APPENDIX  C:  Documents 

A  significant  numfcer  of  "questions  of  Interpretation"  about 
Ada  arose  (primarily  from  implementors).  These  were  questions  about 
unclear  points  In  Preliminary  Ada,  and  were  not  Intended  to  bring  up 
questions  of  design.  The  objective  was  to  answer  questions  of 
immediate  Importance  to  implementors  and  users  In  general. 

These  questions  were  submitted  to  the  language  design  team 
and  were  answered  in  November  1979.  It  was  planned  that  the  asking 
and  answering  of  questions  would  be  an  ongoing  process,  but  few 
questions  came  up  later. 
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tt  should  bo  rocollod  that  thoao  quastlons  and  answers  cafor 
to  Preliminary  Ada  only  and  nay  bo  irrolavant  or  Ineorroct  with 
respect  to  Pinal  Ada. 

The  questions  and  tholr  respective  answers  are  found  In  the 
file  Questions. Answered.  Both  question  and  answer  are  preceded  by  a 
section  number. 


APPENDIX  Ot  Documents  Maintained  By  Xnternetrlcs  Por  Ada 
fast  and  Evaluation 


Nine  types  of  documents  have  been  archived'  durlnq  the  Test 
and  Evaluation  process.  Each  has  Its  own  loq  and  set  of  files 
containing  the  text  of  those  Individual  documents  which  have  been 
received  in  machine  form.  Logging  conventions  and  file  naming 
conventions  are  consistent  over  types.  Each  log  file  Is  named  XXX. LOG 
where  *XXX*  is  a  3  letter  code  for  the  type.  The  text  of  documents  Is 
stored  In  files  naejd  XXX. 001,  XXX. 002,  XXX. 003,  etc.  Again,  *XXX*  la 
the  3  letter  code  corresponding  to  a  particular  type;  the  sequence 
number  provides  a  uniform  and  unique  reference  to  such  documents. 

Log  flies  contain  one  line  of  summary  Information  about  each 
document  of  the  type  they  log:  a  sequence  number,  length,  source,  and 
subject.  All  log  files  contain  at  least  a  sequence  number  and  source. 
Post  log  flies  also  record  the  length  of  the  documents.  An  entry  of  0 
in  this  field  Indicates  that  the  document  Is  not  available  on-line. 

The  source  Is  the  person(s)  or  organization  submitting  the 
document.  If  an  institutional  affiliation  Is  known  it  is  put  In 
parentheses  after  the  author's  name.  Some  documents  have  been 
submitted  without  an  indication  of  source;  others  h'-ve  only  an 
institution's  name.  Note  that  should  a  document  have  as  Its  source 
the  name  of  an  institution,  its  contents  does  not  necessarily  reflect 
the  official  position  of  that  organization. 

The  subject  field  is  an  attempt  to  encapsulate  in  a  very 
small  space  the  most  informative  title  or  summary  for  a  given  comment. 
If  a  subject  reaches  a  conclusion,  that  conclusion  is  briefly 
indicated;  if  a  comment  indicates  a  problem  in  a  certain  area,  that 
problem  Is  made  as  explicit  as  possible  in  the  small  field  available. 

An  entry,  then,  looks  like  this: 


Doc  f  Length 
001  32  pgs 


Source 

J.  Jones  (X  Corp.) 


Subject 

Parameterized 
Types  Needed 


Text  files  are  simply  on-lina  copies  of  the  original 
documents.  If  the  document  was  mailed  to  us  via  the  Arpanet  the  block 
header  is  retained  for  reference. 

Document  Types  Logged 

1.  Phase  Two  Reviews  (P2R) 

These  documents  are  not  actually  available  on  line,  but  are 
nonetheless  logged  in  order  to  establish  sequence  numbers  by  which 
they  may  be  uniquely  Identified. 

Log  file  :  P2R.L0G 

Text  files:  P2R.001,  P2R.002,  P2R.003,  ... 


2.  Evaluation  Reports  (EVR) 

Evaluation  reports  include  extracts  of  selected  Phase  Two 
Reviews  as  well  as  portions  of  documents  previously  designated  as  *A11 
Others.*  Most  documents  of  this  type  are  available  as  on-line  text. 
The  set  of  EVR's  was  essentially  closed  rather  early.  Newer  documents 
are  generally  archived  as  one  of  the  types  described  below. 

Log  file  :  EVR.LOG 

Text  files:  EVR. 001,  EVR.002,  EVR. 003,  ... 


3.  Language  Issue  Reports  (LIR) 

Language  Issue  Reports  are  received  by  Intermetrics  from  the 
community  at  large. They  must  generally  be  in  the  format  specified  by 
HOLWG  in  order  to  be  classified  as  LIR's.  About  30%  of  these  were 
submitted  in  machine  form  (either  over  the  Arpanet  or  by  transportable 
media)  and  are  therefore  on-line. 

Log  file  :  LIR. LOG 

Text  files:  LIR. 001,  LIR. 002,  LIR. 003,  ... 

4.  Comments  (COM) 

There  are  Comments  of  many  types:  comments  on  LIR's,  short 
points,  questions,  dialogs  on  certain  Issues  etc.  In  general,  whereas 
LIRs  are  intended  to  address  one  topic  each,  comments  may  address  a 
range  of  topics  within  one  document.  This  often  leads  to  more  general 
comments,  or  to  comments  related  to  an  overall  analysis  of  suitability 
of  Ada  to  particular  areas.  The  titles  of  comments  are  therefore  less 
specific  than  those  of  LIR's.  Comments  are  heterogeneoty  in  form, 
content,  and  topicality.  MSG  headers  are  retained  for  each  comment  in 
order  to  preserve  their  history. 

Log  file  :  COM. LOG 

Text  files:  COM. 001,  COM. 002,  COM. 003,  ... 


S.  Position  Papers  (POS) 

Various  individuals  or  groups  were  expected  to  submit 
position  papers.  These  were  to  be  in-depth  treatments  of  specific 
problems  or  related  issues.  This  has  not  proven  to  be  a  popular  type 
of  submission. 

Log  file  :  POS. LOG 

Text  files:  POS. 001,  POS. 002,  POS. 003,  ... 


(S.  Draft  Chang*  Requests  (DCR) 

As  described  in  section  2,  a  formal  procedure  mss  established 
whereby  drafts  of  proposals  for  language  changes  written  by 
Intermetrics  and  discussed  by  the  Distinguished  Reviewers  would  be 
submitted  for  review  and  action  by  HOLWG. 

Those  documents,  called  Draft  Change  Requests,  were  generated 
until  the  procedure  was  discontinued.  They  were  and  still  are 
considered  drafts;  their  presence  in  the  log  does  not  Indicate  their 
evolutionary  disposition. 

During  the  review  process,  certain  Draft  Change  Requests 
(OCR's)  underwent  revisions,  reflecting  the  comments  and  opinions 
expressed  during  Reviewers'  Meetings.  A  version  number  is  thus 
appended  to  the  name  of  all  such  files.  The  log  indicates  the  moat 
current  version. 

Log  file  :  OCR. LOG 

Text  files:  DCR. 001,  DCR. 002,  DCR. 003,  ... 

7.  Language  Design  Notes  (LDN) 

These  are  proposals  from  CII-HB  for  changes  to  the  language. 
They  should  not  be  construed  as  a  commitment  by  the  language  design 
team  to  Implement  the  changes. 

Log  file  :  LDN. LOG 

Text  files:  LDN. 001,  LDN. 002,  LDN. 003,  ... 

8.  Official  Problem  Acknowledgments  (OPA) 

These  are  statements  about  language  problems  officially 
recognized  by  the  CII-HB  Design  Team. 

Log  File  :  OPA. LOG 

Text  Piles:  OPA. 001,  OPA. 002,  OPA. 003,  ... 

The  full  logs  appear  in  Appendix  P. 


APPENDIX  D:  Accessing  The  Archive 

The  files  described  have  been  made  available  for  public 
Inspection  and  us*  over  the  Arpanet  at  the  University  for  Southern 
California's  Information  Sciences  institute  machine  *E*,  Arpanet 
addiess  USC-isfE. 

The  ISIS  machine  is  a  Tops-20  system.  It  accepts  Pile 
Transfer  Protocol  (FTP)  and  Remote  Login  (Telnet)  connections  across 
the  Arpanet.  Files  relating  to  Ada  test  and  evaluation  are  found  on 
the  disk  directory  <TNE-Archive>.All  comments  on  the  Ada  language 
which  were  submitted  via  Arpanet  mail  are  stored  here,  or  archived  on 
the  ISI  magnetic  tap*  backup. 


*> 
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During  eh*  T*st  and  Evaluation  period,  all  th*  Ellas 
dascrlbad  hav*  baan  sad*  available  on-llna  for  public  access  by  eh* 
coamunley.  The  files  will  continue  to  be  accessible  on-line 

indefinitely,  although  requests  say  have  to  be  entered  to  th*  ISI 
system  for  retrieval  of  files  from  tertiary  (magnetic  tape)  storage. 

An  anonymous  account  is  available  for  Pile  Transfer  Protocol 
connections. 


The  following  dialogue  is  an  example  of 


program: 

Ftp 

...machine  response 
Conn  ISIE 

...machine  response 
Login  Anonymous  your_name 
...machine  response  — 

Get  <TNE-ARCHI VE>  file  name 


— invoke  Ftp 
—connect  to  tSIE 
—login  to  tSIE 
—do  file  transfer 


a 


typical  FTP  User 


Disc 

Quit 


—disconnect  froa  ISIE 
— return  from  FTP 


APPENDIX  E:  TER  Code  Breakdown 


Many  participants  In  the  TSE  analysis  submitted  algorithms 
written  in  a  language  normally  used  by  the  participant,  and  often 
included  a  version  of  that  algorithm  written  in  Ada;  this  offered  not 
only  an  excellent  means  of  comparison  between  the  two  languages,  but 
also  helped  illustrate  Ada  in  an  applications  context. 

The  list  below  indicates  which  of  the  submitted  contained 
code  samplings. 

TER  »  Original  Code  Ada  Code 

1  -  A 

2 

3 

4 

5 

6 

7 

8 
9 

18 
11 
12 

13 

14 

15 

16 


E,  D 


A 

A 

A 


A 

A 

A 

A 

A 

C,  B,  A 
B,  A 
A 


. 


71 

72 

73 

74 

75 

76 

77 

78 

79 
88 
81 
82 

83 

84 

85 

86 


APPENDIX  P:  Document 

Loqa 

P2R  * 

SIZE 

SOURCE 

801 

00  pga. 

Lev i n/Jonea/Bl aden ( USAF) 

802 

00  pga. 

(Boeing) 

003 

00  pqa. 

(Lear  Siegler) 

004 

00  pqa. 

(Grumman  -  USAF) 

005 

00  pqa . 

(Boeing  -  USAF) 

006 

00  pga . 

(TRW  -  USAF) 

007 

00  pga. 

(ESD/TOIT  -  USAF) 

008 

00  pga. 

(APCCPC  -  USAF) 

009 

00  pga. 

(Hq.SAC  -  USAF) 

010 

00  pqa . 

(Aeroapace  Corp.  -  USAF) 

011 

00  pqa. 

(RADC  -  USAF) 

012 

00  pqa. 

(TI  -  USAF) 

013 

00  pqa. 

(Sperry  Unlvac) 

014 

00  pqa. 

(French  NOD) 

01S 

00  pqa. 

(Stanford  AI  lab) 
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016 

00  M*- 

(U.  of  Granobla) 

017 

00  P9*  • 

Windaur/Goada(MBSP  Gsr) 

018 

00  M»‘ 

Hllflngar/NawcoB*ar<CHU) 

019 

00  P9*  • 

(TRW  -  USAP) 

020 

00  pgs. 

(BGS) 

021 

00  M‘- 

Lsbllng (POL) 

022 

00  pgs. 

Evans/Mo rgan/Porsdlek  (BBtl) 

023 

90  pq«- 

P*lrtag/Mslllar-S*ith(SRI) 

024 

00  pg»- 

Wulf (CMU) 

025 

00  pgs. 

(OCA) 

026 

00  pgs. 

wi rth (ETH  Zurich) 

027 

00  pg«- 

(CORA DCOM  -  ARMY) 

028 

00  pgs. 

(Brown  U.) 

029 

00  pgs. 

(Swadlsh  ORI) 

030 

00  pg«. 

Blssr (Oonlsr  Systa«  G»bh) 

031 

0o  pq». 

Habarnann  (CMU) 

032 

00  MS- 

(Mitre  Corp.) 

033 

00  pgs. 

(NASA) 

034 

00  pgs. 

(Gsnsral  Elsctrlc) 

035 

00  pgs. 

(Systaa  Consultants,  Inc.) 

036 

00  pg*. 

(I ABC  -  Gar  MOD) 

037 

00  pgs. 

(Unlvarsltat  Karlsruhe) 

038 

00  pgs. 

(UK  Dapt.  of  Industry) 

039 

00  pgs. 

(LPT-B) 

040 

00  pgs. 

(UK  MOD) 

041 

00  pgs. 

Schu«an/Abrial (Prench  Navy) 

042 

00  pgs. 

(Coaiputar  Sclancas  Corp.  - 

USAP) 


042 


0*3 

04'. 


00  pgs. 
00  pgs. 


(0.  Tsxaa) 
(Gansral  * 


ob  Carp.) 


045 

00  pga. 

(HqMC,  Coda  CCA-50) 

046 

00  pgs. 

uoaputar  Selaaca  Dapt.(CMO) 

EVR  t 

size 

SOURCE 

SUBJECT 

001 

17 

pgs. 

(BOLWQ) 

Haahlngton  Rarlav  Suaaary 

002 

09 

PgS. 

Plshar/Watharall 

Pbasa  2  Cbanga  Raquaata 

003 

02 

pgs. 

Vulf 

Changa  Raquaata 

004 

02 

pgs- 

Goad/London 

Changa  Raquaata 

005 

04 

pgs- 

(Navy) 

Languaga  Issue 

006 

01 

pgs. 

(USAF ) 

Languaga  laauaa 

007 

02 

pgs. 

(HOD) 

Languaga  Iaauea 

008 

19 

pgs. 

Intarastrlca 

Languaga  Xasuas 

LIR  * 

SIZE 

SOURCE 

SUBJECT 

001 

01 

Pgs. 

I.C.  Pyla  (iorlc) 

Prograa  Ovarlaya 

002 

03 

pga. 

Andy  Hisgan  (CHU) 

Tlaad  Out  Entry  Calls 

003 

03 

pga. 

Andy  Nlsgan  (CHU) 

TASKING  ERROR  Exaaptlona 

004 

09 

pgs. 

Tlehy/Hubbard  (CHU) 

Saparxta  Compilation 

005 

09 

pga. 

Saza  (CHU) 

Functions  and  VRP's 

006 

07 

pga. 

Saxa/Saltb  (CHU) 

Uaar-Daflnad  Typaa 

007 

04 

pga. 

Hassi'  (DEC) 

TEXT.IO  Proposals 

008 

19 

pga. 

Hllflngar  (CHU) 

Discriminant  Constraints 

009 

41 

pga. 

Hllflngar  (CHU) 

Tasking  Faollltles 

010 

02 

Pga. 

firth  ( RHCS ) 

HOD  Opa-ator 

010 


Oil 

03 

PC*. 

-  90  - 

Firth  (1NCS) 

explicit  Conversion* 

0'2 

02 

PC*. 

T.  Japan  (Hugh**) 

Iteration  Variable 

01} 

03 

PC*. 

Sprlnc*r  (IBM) 

1-0  Fackac* 

014 

02 

PC*. 

HaeLaran  (Boalnc) 

Fortran  Interface 

015 

03 

PC*. 

MaeLtran  (Boalnc) 

entry  Generic  Faraaetera 

016 

02 

PC*. 

Firth  < RMCS ) 

exception  Handling 

oir 

05 

PC*. 

Firth  (RMCS) 

Faraaatar  Binding 

018 

02 

PC*. 

Firth  (RMCS) 

Variant  Record* 

019 

02 

PC*. 

Firth  (RMCS) 

Supprasalng  *33BRf_KRR0R 

020 

1 1 

PC*. 

Firth  (RMCS) 

Saaantlca  of  Hunerlca 

021 

09 

PC*. 

Woodger  (OK) 

LRM  Clarification* 

022 

03 

pc*. 

Firth  (RMCS) 

Task  Taralnatlon 

023 

02 

PC*. 

Firth  (RMCS) 

Compilation  Units 

024 

02 

PC*. 

Firth  (RMCS) 

BZIT  HHEN  extensions 

025 

02 

PC*. 

Firth  (RMCS) 

allocator  Function 

026 

03 

PC*. 

Firth  (RMCS) 

SBLKCT  Guard* 

027 

02 

PC*. 

Firth  (RMCS) 

RRNGK  attribute 

028 

02 

PC*  • 

Firth  (RMCS) 

array  Generic  Faraaatar* 

029 

02 

PS*. 

Firth  (RMCS) 

Derived  Type* 

0  30 

02 

PC*. 

Firth  (RMCS) 

BOOLE**  Type 

031 

03 

PC*. 

Firth  (RMCS' 

Procedure*  In  Taak* 

032- 

01 

PC*. 

T.  Sapan  (Hughaa) 

Recur slve/ Reentrant 

033- 

01 

PC*. 

Taylor  (3oelng) 

assertion* 

034- 

03 

pc*. 

Ooos  (Karlsruhe) 

Diver**  Points 

035- 

03 

pga. 

Goo*  (Karlaruha) 

Funotlons  and  Order 

036- 

02 

PC*. 

Gooa  (Karlaruha) 

Conditional  Coapllatlon 

037- 

01 

PCS. 

(Gar . MOD/I  ABO ) 

absence  of  FRKB 

absence  of  FRBE 


030- 

02  pga. 

(Cap. MOD/I ABC) 

Vtiiblllty  Raatrtotlooa 

039- 

01  pga. 

(Gar. MOD/I ABC) 

Bacupa Ira/ Ra-ant rant 

0*0- 

01  pga. 

(Sar.HOD/IABQ) 

Huaaplc  Lltarala 

0*1- 

01  pga. 

( Gar . MOD/I A8G ) 

Cayword  Ovaploadlng 

0*2- 

01  pga. 

(Gar .MOD/IABG ) 

MOD  Opapatloa 

0*3- 

01  pga. 

(Gar .HOO/IABG) 

Array  Bouada 

0*4- 

01  pga. 

(Gar. MOD/IABG) 

Loop  Syntax 

0*5- 

01  pga. 

(Gap. MOD/IABG) 

IHLIMB  Ppagaa 

0*6- 

02  pga. 

(Gap. MOD/IABG) 

Input/Output 

0*7- 

02  pga. 

(Gar. MOD/IABG) 

Kayworda 

0*0- 

01  pga. 

(Gap. MOD/IABG) 

Onhandlad  Exoaptlona 

0*9- 

01  pga. 

(Gap. MOD/IABG) 

Vlalbllity-Rulaa 

050- 

01  pga. 

(Gap. MOD/IABG) 

j 

Conditional  Bvaluatlon 

051- 

01  Pfi 

(Gap. MOD/IABG) 

Daolaratlon  Syntax 

052- 

oi  pga. 

(Gar. MOD/IABG) 

Syntax  Daaorlptlon 

053- 

01  pga. 

(Gar. MOD/IABG) 

Qaaga  of  DBLAI 

05*- 

01  pga. 

(Gar. MOD/IABG) 

Ineoaplata  Typa  Daolaratlon 

055- 

01  pga. 

(Gar. MOD/IABG) 

Dynaalo  Allocation 

056- 

01  pga. 

(Oar. MOD/IABG) 

Soopa  Rulaa 

057- 

01  pga. 

(Gar. MOD/IABG) 

Bxoaptlona 

050- 

01  pga. 

(Gar. MOD/IABG) 

Abaanea  of  SET  Typa 

059- 

01  pga. 

(Gar. MOD/IABG) 

Pollution  of  Kaaa-apaoa 

060- 

01  pga. 

(Gar. MOD/IABG) 

Low-Laval  Tasking 

06  1  - 

01  pga. 

(Gar. MOD/IABG) 

Aaynobronoua  Conaunloatlon 

062- 

01  pga. 

(Gar. MOD/IABG) 

Storaga  Managaaant 

063- 

02  pga. 

(Gar. MOD/IABG) 

Typa  CHARACTER 

06*- 

01  pga. 

(Gar. MOD/IABG) 

Raoord  Rapraaantatlona 

091- 

03  pga. 

NagIa(Pord  Aaroapaca) 

Intagara 
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065- 

91  pga. 

(Gar  .MOD/IABG) 

Loop  Control 

066- 

02  pga . 

Fifth  (RMCS) 

Nan ad  Block 

067- 

01  pgs. 

Knut  Rlpkln 

One-Component  Aggregates 

068- 

02  pga. 

Knut  Rlpkln 

Modula  Visibility 

069- 

01  pga. 

Plshar/Dawar 

(NYU) 

Suppraaa  Pragma t 

070- 

03  pga . 

Plshar/Dawar 

(NYU) 

Ganarlc  Facility 

971- 

02  pga. 

PI  sher/Dawar 

(NYU) 

Aasert_Error 

072- 

92  pgs. 

Plshar/Dawar 

(NYU) 

Labels  and  Goto's 

973- 

01  pga. 

Pishor/Dewar 

(NYU) 

Boolaan  Operators 

074- 

02  pga. 

FI ahar/Dawar 

(NYU) 

Overloaded  Literals 

075- 

01  pga. 

PI  ahar/Dawar 

(NYU) 

Functions  and  VHP's 

076- 

01  pga. 

Plshar/Dawar 

(NYU) 

Overloading 

977- 

01  pga. 

Plshar/Dawar 

(NYU) 

IN  paraaaters 

078- 

01  pga. 

Plshar/Dawar 

(NYU) 

Keywords 

079- 

01  pga. 

Plshar/Dawar 

(NYU) 

MOD  Operator 

080- 

02  pga. 

Plshar/Dawar 

(NYU) 

Scheduling  Semantics 

081- 

02  pga. 

Plshar/Dawar 

(NYU) 

Priorities 

082- 

01  pga. 

Plshar/Dawar 

(NYU) 

Aliasing 

083- 

01  pga. 

Plshar/Dawar 

(NYU) 

Definition  of  Semaphore 

084- 

01  pga. 

Plshar/Dawar 

(NYU) 

Character  Strings 

08S- 

01  pga. 

Plshar/Dawar 

(NYU) 

Character  Strings 

086- 

01  pga. 

Plshar/Dawar 

(NYU) 

OUT  pa rasa tars 

087- 

01  pga. 

Plshar/Dawar 

(NYU) 

Named  Parameters 

088- 

01  pga. 

Plshar/Dawar 

(NYU) 

No_Value_Brror 

089- 

92  pga. 

Plshar/Dawar 

(NYU) 

Select  Statement 

090- 

02  pga. 

Plshar/Dawar 

(NYU) 

Evaluation  Order 

091- 

03  pga. 

Nagle(Fort)  Aerospace) 

Integers 

93  - 


092- 

02  p«a. 

Firth  (RHCS) 

Ovarlapplnc  Slloa  Asaicnnant 

093- 

01  p«a. 

(Oer.MOD/IABO) 

Allcnnant  Clausa 

099- 

01  p(s. 

(Oer.MOD/IABO) 

END  Statanants 

095- 

02  pcs. 

Indy  Blactn  (CKO) 

Package  Elaboration 

096- 

03  PCS. 

Hlscsn/Tlehy  (CKO) 

Packac*  Initialisation 

097- 

02  pcs. 

Indy  Hljj.n  (CKO) 

Subprocran  Rasult  Valuas 

098- 

09  pcs. 

Bruos  Leverett  (CKO) 

Control  Charactars  In  I/O 

099- 

02  pcs. 

Bruoa  Leverett  (CHU) 

Pornattlnc:  Put  and  Rap 

100- 

02  pcs. 

Mary  Shau  (CKO) 

Darlvad  Typaa 

101- 

09  pcs. 

Hu.  A.  Hulf  ( CHU ) 

Aceass  Typa  Constants 

102- 

02  pcs. 

David  B.  Snlth  (CKO) 

Acoass  Typaa 

103- 

02  pcs. 

David  R.  Snlth  (CHU) 

Tha  Charaotars  *,  t,  #  and  1 

10*- 

02  pcs. 

David  R .  Snlth  (CKO) 

Floatlnc  Point  Valuas 

105- 

02  pcs. 

David  R.  Snlth  (CMU) 

Rafaranoa  Manual  Froblana 

106- 

01  pcs. 

David  R.  Snlth  (CKO) 

Array  I/O 

107- 

02  pcs. 

David  R.  Snlth  (CKO) 

Binary  Pllaa/Mlxed  Typaa 

108- 

03  PCS. 

David  R.  Snlth  (CKO) 

Control  Charaotars 

O 

•o 

1 

02  pcs. 

David  R.  Snlth  (CKO) 

I/O  Bufferlnc 

1  lo¬ 

01  pcs. 

David  R.  Snlth  (CKO) 

Raal  Nunbars 

ll  1  - 

05  pcs. 

Ronald  Brandar  (CKO) 

Quallflad  Ezprasslons 

1 12- 

02  pcs. 

Ronald  Brandar  (CKO) 

Soopa  of  Cabals 

113- 

09  pcs. 

David  R.  Snlth  (CKO) 

Ranca  Constraints 

114- 

02  PCS. 

Vn.  A.  Hulf  (CKO) 

Propartlas  of  Oparators 

115- 

01  pcs. 

Josaph  Havsinar  (CKO) 

Inadequacy  of  Index 

116- 

02  pcs. 

Josaph  Navoonar  (CKO) 

Problens  with  0RD 

1 1T- 

01  pcs. 

Nasal  (DEC) 

String  Lencth 

118- 

01  pcs. 

I.C.  Pyla  (Torlt) 

Anblcuous  Stubs 

9* 


1  19- 

02  pea. 

Ooodanouch  (SofTaoh) 

FAILURE  Cxoaptloa  aabiculty 

120- 

02  pea. 

(G«P . MOD/I ABO ) 

Saparata  Coapllatlon 

121- 

03  pea. 

Bruoa  Lavaratt  (CMU) 

Short  Clroutt  Conditions 

122- 

03  pea. 

(Oar .MOD/IABQ ) 

Soopa  or  labala 

123- 

13  pea. 

S.  Tan  Horn 

Dynaalo  Storaea  Allooatlon 

121- 

03  pea. 

Firth  ( RHC3 ) 

Taak  Runtlaa  Idaatlty 

125- 

01  pea. 

Flnaath  (MIT) 

Tab  Stop  Coluana 

126- 

01  pea. 

Flnaath  (HIT) 

Striae  Langth 

127- 

01  pea. 

Flnaath  (HIT) 

FREE  Stataaant  aaadad 

128- 

09  pea. 

Firth  (RHC3) 

Idantlf loatlon  of  stubs 

1 29- 

01  pea. 

Flnaath  (HIT) 

Basad  Tarlablaa 

130- 

01  pea. 

Flnaath  (HIT) 

Indapandaat  Coapllatlon 

131- 

10  pea. 

Firth  ( RHC3 ) 

Ovarloadlae 

1 32- 

03  pea. 

Firth  (RHC3) 

Aeoaaa  Constant 

l  33- 

05  pea. 

Firth  (RHCS) 

Virtual  Raeord  Coapononta 

13*- 

01  pea. 

Thoapaon  (TRV/D33Q ) 

Array  Accrues taa 

135- 

01  pea. 

I.C.  Pyla  (York) 

9CC>*aca9a  Rotation 

136- 

01  pea. 

I.C.  Pyla  (Tork) 

Syntax  of  Baas* 

1 37- 

00  pga. 

T.  Sapan  (Hughar) 

Naad  BLOCK  DATA 

138- 

oo  pea. 

F.  Cox  (Gaorgla  Taeh) 

Visibility  Control 

139- 

oo  pea. 

F.  Cox  (Oaorcla  Taoh) 

Visibility  Rastrlotlona 

190- 

00  pea. 

F.  Cox  (Oaorcla  Taoh) 

Saparata  Subunits 

191- 

02  pea. 

Habaraann  (CHO) 

Valua  Ratnrnlng  Froaaduraa 

192- 

03  pea. 

Habarainn  (CMU) 

Paraaat arlxad  Typos 

1*3— 

02  pea. 

Burklnahaw  (IABQ) 

Dafault  Valuss  for  Paraaatars 

1*9- 

01  pcs. 

Hlohaal  Coapton 

Ordar  of  Coapllatlon 

195- 

01  pea. 

Hiohaal  Coapton 

EXIT  and  othor  Loop  Constructs 
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146- 

07  pg*. 

MacLaran  (Boalng) 

Intarrupt  Randlars 

147- 

04  pg*. 

MacLaran  (Boalng) 

Sharad  Data 

148- 

92  pg». 

Lavlna  (Incaraatrlca) 

Nunarlc  Lltarala 

149- 

01  pg«. 

Lavina  (Intaraatrlcs) 

Variant  Racorda 

150- 

02  pqi. 

Lavlna  (Intaraatrlea) 

RANGE  notation 

151- 

01  pgs. 

Lavlna  (Intaraatrlca) 

Loop  and  Block  Labal  Scopa 

152- 

01  pqa. 

Lavlna  (Irtaraaerlca) 

Array  Bounds  Spaclflcatlon 

153- 

01  pg«. 

Lavlna  (Intaraatrlca) 

Enuaaratlon  Lltarala 

154- 

02  pga. 

Lavlna  (Intaraatrlca) 

Intagar  Typa  Definition  Form 

155- 

01  pga. 

Lavlna  (Intaraatrlca) 

T'PRED  and  T'SUCC 

156- 

«1  P9«. 

Lavlna  (Intaraatrlca) 

Coaponant  Salactlon 

157- 

04  pga. 

T.  w.  Jonaa 

Divarsa  Points 

158- 

01  pga. 

R.  Schwarts 

Aliasing  Rastrlctlona 

159- 

02  pga. 

R.  Schwarts 

RENAMES  Stataaent 

160- 

01  pga. 

J.  Kaaton  (MITRE) 

Pragaa  Saaantlcs 

161- 

04  pga. 

Firth  (RMCS) 

Models  of  Access  Types 

162- 

02  pga. 

0.  Parry  (CMU) 

Peraisslve  Syntax 

163- 

02  pga. 

0.  Parry  (CMU) 

Partial  Aggregate  Initialization 

164- 

02  pga. 

D.  Parry  (CMU) 

Consistent  Initialization 

165- 

00  pga. 

J.  T.  Galkowakl  (IBM) 

Field  Naaes  In  Variants 

166- 

00  pga. 

J.  T.  Galkowakl  (IBM) 

Recursion  Is  Efficient 

167- 

00  pga. 

J.  A.  Edwards 

Obsolete 

168- 

00  pga. 

J.  A.  Edwards 

Obsolete 

169- 

00  pga. 

J.  A.  Edwards 

Obsolete 

170- 

00  pga. 

Joa  Parlay 

Obsolete 

171- 

00  pga. 

J.  A.  Edwards 

Obsolete 

172- 

00  pga. 

J.  A.  Edwards 

Obsolete 

173- 

00  pgs. 

J.  A.  Eduards 

17»- 

00  pgs. 

J.  A.  Eduards 

j.  i.  Eduards 

175- 

00  pgs. 

176- 

oo  pga. 

D.  Jonas 

177- 

01  pga. 

T.  Hastings  (DEC) 

178- 

01  pga. 

T.  Hastings  (DEC) 

179- 

01  pga. 

John  Sautar  (DEC) 

180- 

01  pga. 

Oannla  Hobla 

181- 

01  pga. 

Michaal  Eing  (HHC) 

182- 

01  pga. 

Michael  King  (HHC) 

183- 

01  pga. 

Michaal  King  (*«C) 

ian- 

02  pga. 

Michael  Kin*  (**C) 

185- 

02  pga. 

Michaal  Kin*  (**C) 

186- 

01  pga. 

Michaal  King  (**C> 

187- 

01  pga. 

g ,  Krutar  (BBC) 

188- 

01  pgs. 

B.  Krutar  (HBL) 

189- 

01  pga. 

*.  Krutar  (*KL) 

10 

o 

» 

01  pga. 

r,  Krutar  (**L) 

191- 

01  pgs. 

8.  Krutar  (HBL) 

192- 

01  pga. 

B.  Krutar  (HHL) 

193- 

01  pga- 

R.  Krutar  (HBL) 

19**- 

02  pga. 

R.  Krutar  (HBL) 

195- 

03  Pta. 

Marc  Hubbard  (HVC) 

H,  Sober  (BHC) 

196- 

03  P8*. 

197- 

02  pga. 

H.  Hattataln  (IAB0) 

198- 

02  pgs. 

H.  Rubor  (HHC) 

199- 

02  pga. 

Latina  (Intarmatrlo 

Obsolete 
Obsolete 
Obsolete 
MOD  Funotlon 
9a ryln*  String# 

Functional  Arguments 
Floating  Exponents 
Interrupt  Handling 
TIB  Charaoter 
yaad  for  Simulated  ID 
«njk»l  and  FffT_LI«S  Heed.d 

Exception  Handlar 

Ha ad  Mora  Loop  Constructs 

Uaok  of  Oaar  Daflnad  Literals 

PACKAGE  and  TASK 

PROCEDURE  and  E*T*X 

Entry  Calla 

Subprogram  Calling 

Subprogram  Calling 

ADD  THE*  and  0*  SIS* 

Coiaant  Coovantlon 
EXIT  Statanant 
Flxad  Point  Bounding 
Oanarlo  Facility  Inadequate 
Tasting  Faotlltlaa 
Seopa  Bulan  Ambiguous 
a)  Short  Cir-ult  Conditions 
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200- 

01 

P«s. 

Levins  ( Intereetrlca ) 

Aooess  Constants  too  Restricted 

201- 

01 

PCS. 

Levins  (Internetrlas) 

Anonyaous  Aooess  Types 

202- 

03 

PCs. 

Levine  ( Interne trios) 

Ada  Oraanar  Allows  Bapty  Plaids 

203- 

02 

PCs. 

Bills  Thonee  (SDL) 

Identification  of  Stubs 

209- 

02 

PCs. 

0.  Botkin  ( CNO) 

Derived  Types  in  Ada 

205- 

02 

PCs. 

0.  Botkin  (CNO) 

Ada  Syntan 

208- 

02 

PCs. 

D.  Botkin  (CM0) 

Ada  1/0 

207- 

00 

PCS. 

Hloneel  Conpton 

Ralak  Generic  Para  Constraints 

208- 

00 

PCS. 

Michael  Conpton 

Range  Cheeking 

209- 

00 

PCS. 

Hiohael  Conpton 

Assertion  facilities 

210- 

00 

PCS. 

L.  J.  Callaher 

Variant  Records  of  Type  Aooess 

211- 

00 

PCS. 

H.  Johnson  (Boeing) 

Macro  Facility 

212- 

00 

PCS. 

8.  Johnson  (Boelnc) 

PRBB  Statsaent  is  Reeded 

213- 

00 

PCS. 

J.T.  Oalkovski  ( IBH) 

field  Haase  in  Variants 

219- 

00 

PCS. 

Coos  (Karlsruhe) 

Subarogran  Calls 

215- 

00 

PCS. 

Sooa  (Karlsruhe) 

Ganerla  Clauses 

216- 

00 

PCS. 

Coos  (Karlsruhe) 

Aooess  Type  Objects 

217- 

03 

PCS. 

Bills  Thonas  (SOL) 

Inconsistencies  in  the  LRM 

218- 

01 

PCS. 

OK  DOI  RTL/2  Tean 

Bull  Statsaent 

219- 

02 

PCS. 

OK  DOI  RTL/2  Tean 

Ose  Clause 

220- 

02 

PCs. 

OK  DOI  RTL/2  Tean 

Enpty  Subranges 

221  - 

02 

PCS. 

OK  DOI  BTL/2  Tean 

Types  of  Array  Bounds 

222- 

02 

PCs. 

OK  DOI  RTL/2  Tean 

Maned  Blocks 

223- 

02 

PCS. 

OK  DOI  RTL/2  Tean 

Range  Motatlon 

229- 

01 

PCs. 

OK  DOI  RTL/2  Tean 

Loop  Indioes 

225- 

03 

PCs. 

OK  DOI  RTL/2  Tean 

Syntax  of  Hanes 

226- 

02 

PCS. 

OK  DOI  RTL/2  Tean 

Visibility  Rules 

/ 

/ 
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227- 

03  PC*. 

OK  001  RTL/2  Tsaa 

Arrays  aad  Strings 

228- 

02  pg*. 

OK  001  8TL/2  Tsaa 

Syntax  Bulss  for  Typos 

229- 

00  pc*. 

Mtahsal  Coapton 

USE  Clans*  Bsduadant 

230- 

00  pc*. 

Mlshssl  Coapton 

Short  Clroult;  Boolsaa  Syntax 

231- 

00  pc*. 

Mlohaal  Coapton 

SELECT  Statsaont 

232- 

00  pc*. 

Hlohasl  Coaptoo 

Flxad  Point  Tarlablsn 

233- 

00  pc*. 

Mlobaol  Coapton 

Oarbag*  Collsotlon 

23*- 

00  PC*. 

Hlohasl  Coapton 

RBAOOHLT  EXPORT  Dsslrsd 

235- 

00  PC*. 

Mlohaal  Coapton 

RANGE  Attrlbut* 

236- 

00  PC*. 

Hlohasl  Coapton 

Prlvat*  Parts  of  Spself lcatlons 

237- 

00  pgs. 

Mlohaal  Coapton 

Rsstrlotsd  Typos 

238- 

00  PC*. 

Hlohasl  Coapton 

Poraattad  I/O 

239- 

00  pgs. 

Hlohasl  Coapton 

Intsrrupts;  Contsxt  Switching 

2*0- 

00  pga. 

Hlohasl  Coapton 

Exoaptlon  Daolaratlon 

2*1- 

00  pgs. 

Mlohaal  Coapton 

Conpllatlon  Onlt  Gansalogy 

2*2- 

00  pgs. 

J.  k.  Kdvard* 

EXIT  and  ABORT 

2*3- 

00  pgs. 

J.  A.  Kdvards 

Short  Clroult  Conditions 

2*«- 

00  pgs. 

J.  A.  Edwards 

Exoaptlon  Ossrhsad;  Assart 

2*5- 

00  pgs. 

Jo*  Fsrlsr 

Bitstring  Litorals 

2*6- 

00  pga. 

J.  A.  Edwards 

Storag*  Hanagaaant 

2*7- 

00  pgs. 

J.  A.  Edwards 

Paokac*  Daolaratlon* 

2*8- 

00  pgs. 

J.  A.  Edwards 

Task  Sohadullng;  Salaot 

2*9- 

00  pga. 

J.  A.  Edwards 

P0R/0SE  Ovarloadlng 

250- 

00  pgs. 

J.  A.  Edwards 

Salaotor  ate.  Syntax 

251- 

00  pgs. 

J.  T.  Galkowslcl  (IBM) 

WHILE. ..LOOP  Suparfluous 

252- 

00  pgs. 

J.  T.  Oalkowskl  (IBM) 

Position  of  DSC 

253- 

00  pgs. 

J.  T.  Oalkowskl  (IBM) 

Punotlons  and  TRP's 

/ 
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25*- 

00  pgs. 

•>.  T.  Calkowskl 

255- 

00  pgs 

J  •  T.  Oalkowskl 

256- 

00  pgs. 

J.  T.  Galkcvskl 

257- 

00  pgs. 

2.  T.  Calkowskl 

258- 

00  pgs. 

A.  0.  8.  Cooper 

259- 

00  pgs. 

A.  0.  B.  Cooper 

260- 

00  pgs. 

A.  0.  B.  Cooper 

261- 

00  pgs. 

A.  0.  B.  Coopar 

262- 

00  pgs. 

A.  G.  B.  Cooper 

263- 

00  pgs. 

A.  G.  B.  Cooper 

26*- 

00  pgs. 

A.  G.  B.  Coopar 

265- 

00  pgs. 

A.  G.  B.  Coopar 

266- 

oo  pgs. 

A.  G.  B.  Coopar 

267- 

00  pgs. 

A.  G.  B.  Cooper 

268. 

00  pgs. 

A.  G.  B.  Coopar 

269- 

00  pgs. 

* «  G.  8.  Coopar 

270- 

00  pgs. 

A.  J.  M.  Tan  Gils 

271- 

00  pgs. 

A.  J.  M.  Van  Gils 

272- 

00  pgs. 

A.  J.  m.  Tan  Gils 

273- 

00  pgs. 

A.  J .  M.  Tan  Oils 

27*- 

00  pgs. 

A.  J.  M.  Tan  Gila 

275- 

00  pgs. 

A.  J .  M.  Tan  Glia 

276- 

00  pgs. 

A.  J .  m.  Tan  Gila 

277- 

00  pgs. 

A.  J .  m.  Tan  Gils 

278- 

00  pgs. 

A.  J.  m.  Tan  Glia 

279- 

00  Pgs. 

A.  J.  M.  Tan  Gils 

280- 

00  pgs. 

A.  J.  m.  Tan  Gils 

(IBM)  Forbid  Intertask  Data  Sharing 
(IBM)  Currant  Tasking  Boat 
(IBM)  Currant  Binding  Saaantlea  Baat 
(IBM)  Overlapping  Slice  Assignment 
Qanarlo  Type  Paraaatars 
Selective  Inportlng 
Bit  Foaltlon  Attribute* 
Inoraaantlng  ato.  (aalf) 

00T  Paraaatars  In  Calls 
'Sis*  of  Prograa  Units 
loncont lgulty  and  Addresses 
Battar  Strings  Daslrad 
Subtypes  of  Anonyaous  Tjrpas 
Keyword  Paraaatars  Liked 
Operation  Inbarltanoa 
Overloaded  Relational  Operators 
Syntax  of  Aeouraoy-Conatraint 
Prooadura  Call  on  LH3 
Syntas  of  Prlaary 
Subprograa  Attrlbuta 
Short  Circuit  Conditions 
WHILE  Bsdundant 

Private  Representation  Seolfleat; 
Overloading  Dlaaablguatlon 
Olva  Initiate  Paraaatars 
Conststaney  for  Tanks,  Modules 
ACCEPT  Paraaatars  Scope 
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281- 

00  pga. 

A.  J.  M.  Van  Otis 

Visibility  Lists 

282- 

00  pg*. 

1.  J.  H.  Vsn  Otis 

283- 

00  pga. 

t.  J .  M.  Van  Otis 

01 strlbutad  Systans 

289- 

00  PCS. 

1.  J.  M.  Van  Gils 

Task  Tarninatloo 

285- 

00  PCS. 

A.  i.  H.  Van  Gila 

Exeapt  Propagation  fron  Bandasuou 

286- 

00  PC*. 

k.  J.  H.  Van  Gils 

Raprasantatlon  of  Enunarals 

28T- 

00  PCS. 

k.  J.  M.  Van  Gils 

Syntax  of  Oanarlo  Paranatar 

288- 

00  PCS. 

k.  J.  H.  Van  Gils 

GanaPlo  Instantiation  Sanantlos 

289- 

00  PCS. 

k.  J.  N.  Van  Gils 

Ganarle  Paranntera 

290- 

00  PCS. 

A.  J.  M.  Van  Gils 

'Slxa  of  Ganario  Typa  Paranatara 

291- 

00  PCS. 

A.  J.  M.  Van  Gils 

Allow  EntPian  as  Ganarle  Parana ta 

292- 

00  PCS. 

A.  J.  M .  Van  Oils 

Syntaetio  Position  of  Pragnas 

293- 

00  pcs. 

A.  J.  M .  Van  Gils 

Syntax  Anblgnoua 

299- 

02  PCS. 

William  A.  Whltakar 

Radix  Syntax 

295- 

01  PCS. 

Wlllian  A.  Whltaltap 

Conplatanass  of  Formal  Syntxx 

296- 

00  PCS. 

J .  T.  Galkovakl  (IBM) 

Intarfaea  Conwantlon 

29T- 

02  PCS. 

FiPth  ( RHC3 ) 

Charaotap  Lltarals 

298- 

01  PCS. 

Will  tan  A.  Whltaltap 

Prlopltias  sad  Hnrdvarn 

299- 

01  PCS. 

Wlllian  A.  Whltaltap 

I/O  Porsattlng 

300- 

02  PCS. 

Wllllan  A.  Whltaltap 

OPTIMIZE  SPACE  OP  TIME 

;oi- 

03  PCS. 

Wlllian  A.  Whltaltap 

Sattsr  TIME  and  IETEBVAL 

302- 

01  PCS. 

GK  DOI  Cor al66  Taan 

RENAMES  Allowad  Only  ss  Daolapstl 

303- 

01  PCS. 

OK  DOT  3oral66  Taan 

Osa  and  Raatrletad 

309- 

01  PCS. 

Ellis  Thonas  (SDL) 

Saparats  Compilation  and  OaaPload 

305- 

01  PCS. 

OK  001  Copal66  Taan 

Osa  and  Nana  Spaea 

306- 

02  PCS. 

Goodanough  (Sof'faoh) 

Plxsd  Point  •aprasantntlons 

307- 

02  PCS. 

Wlllian  A.  Whltaltap 

Osa  Fortran-Ilka  Ralatlonal  Opapa 
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308- 

03  P9«- 

wlllla*  A.  Whltsksr 

Banish  Vsrtical  Bar  (1) 

309- 

01  pgs. 

Willis*  A.  Whltsksr 

Rsnaas  •Unsaf*_Progra**lng# 

318- 

01  pgs. 

Bills  Tho*ss  (SDL) 

Modulo*  Without  Bodlas 

311- 

02  pgs. 

Tho*ss  k  Gllbsrt  (SDL) 

Local  Tasks 

312- 

00  M*. 

M.  Dsvlln  (AFSCF/BJB) 

Banish  Subtypss 

313- 

02  pq«- 

Willis*  A.  Whltsksr 

Right  Arrow  Symbol 

314- 

01  P9«* 

Willis*  A.  Whltsksr 

Quota  Charactsr 

315- 

02  pgs. 

Willis*  A.  Whltsksr 

Uas  *« ‘  for  Assignment 

316- 

02  pq«- 

Willis*  A.  whltsksr 

Rang*-' Endpoints 

317- 

02  pgs. 

Willis*  A.  whltsksr 

MOD  and  REM 

318- 

01  pgs. 

Willis*  A.  whltsksr 

LRM  Erratu* 

319- 

02  pgs. 

MacLaran  (Sosing) 

Tlosd  Out  Entry  Calls 

320- 

01  pos. 

Ellis  Thomas  (SDL) 

Nuabar  Syntax 

321- 

01  pgs. 

Thomas  k  Gllbsrt  (SDL) 

Sspsrata  Cowpllation  k  Linking 

322- 

01  pgs. 

Lisbsrwsn  k  Xlsrnan 

Paramstsr  Syntax 

323- 

01  pgs. 

Liobarman  k  Xlsrnan 

Moaning  of  •Modula* 

324- 

01  pgs. 

Liebsrman  k  xlsrnan 

Eliminate  Goto 

325- 

01  pgs. 

Lisbaraan  k  xlsrnsn 

Packags  Elaboratlon/Ini tializatic 

326- 

01  pgs. 

Liabsraan  t  Xlsrnan 

Local  Static  Vsriablss 

327- 

82  pgs. 

T.  Conrad  (NOSC) 

Davies  I/O 

328- 

01  pgs. 

T.  Conrad  (HUSC) 

Educational  Matsrials  Moodsd 

329- 

01  pgs. 

Willis*  A.  Whltsksr 

Paramstsr  Syntax 

330- 

03  pgs. 

Willis*  A.  Whltsksr 

Floating  Praclslon  not  Digits 

331- 

02  pgs. 

Willis*  A.  Whltsksr 

Non-Binary  Machlnss 

332- 

01  pgs. 

wlllla*  A.  Whltsksr 

•Do'  In  Accspt 

333- 

02  pgs. 

Willis*  A.  Whltsksr 

Prsdsf Ins  Oparators  for  All  Typos 

334- 

02  pgs. 

Willis*  A.  Whltsksr 

SsJsction  by  Parsnthssss 
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335- 

00  M»- 

T.  A. 

Montgomery 

Procedural  Variables  and  Arguaant 

336- 

00  M*- 

T.  A. 

Montgomery 

Arrays  of  Arrays 

337- 

M  M*  • 

T.  A. 

Montgomery  1 

'  Locatlvas 

338- 

86  M*- 

T.  A. 

Montgomery 

Slicing  Cluaay 

339- 

00  Mi- 

T.  A. 

Montgomery 

Local  Declarations  Verbose 

340- 

01  Mi- 

T.  A. 

Montgomery 

Conditional  Expressions  Desired 

341- 

14  MS- 

T.  A. 

Montgomery 

Alloa  Stataaants  In  Conditions 

342- 

00  pq*. 

T.  A. 

Hontgoaary 

Bit  Vector  Operators 

343- 

00  pqa. 

T.  A. 

Hontgoaary 

Hull  Valve 

344- 

00  pq*- 

T.  A. 

Hontgoaary 

VRP's  Overly  Constrained 

345- 

00  pq«. 

T.  A. 

Hontgoaary 

Embedded  Coaaents  Desired 

346- 

00  pqs- 

T.  A. 

Hontgoaary 

Hake  *_*  Mot  Significant 

347- 

00  M«- 

T.  A. 

Hontgoaary 

Paraaeter  Association  Symbols 

348- 

00  MS- 

Arthur  Sorkin  (SEL) 

Dangling  References 

349- 

00  pqs. 

jlnet 

1 

Loula  {IBM) 

Word-level  Referencing 

350- 

00  MS- 

jlnet 

Loula  (IBM) 

Fixed  Point  Representation 

3S1- 

00  MS- 

Janet 

Loula  (IBM) 

Where  la  Bit  07 

352- 

00  ms- 

Janet 

Loula  (IBH' 

Address  Specification  Vague 

353- 

02  MS- 

MacLaren  (Boeing) 

preeaptlve  Priority  Scheduling 

354- 

02  MS- 

UK  DOt  Coral66  Team 

SUSPEND  and  RESUME  of  Tasks 

355- 

01  M«- 

UK  001  RTL/2  Team 

Default  Initial  Values  for  All  T) 

356- 

01  MS- 

UK  001  RTL/2 

The  notation  .all  Is  strange 

357- 

01  MS- 

UK  DOT  RTL/2  Team 

Precedence  of  Unary  Operators 

350- 

01  ms- 

UK  001  RTL/2  Teaa 

MOD  Operators 

359- 

01  MS- 

UK  DOt  RTL/2  Tea* 

Entry  Calls  eith  Tineout 

360- 

01  ms- 

UK  DO I  Coral66  Teaa 

Timeouts 

361- 

82  ms- 

UK  DOt  Coral66  Team 

Incomplete  Record  Assignment  Desi 
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362- 

81  pgs. 

UK  DOI  Co rsl66  Team 

Quoted  Litoral  Asbigulty 

363- 

82  pgs. 

UK  DOI  Coral66  Tsas 

Task  varlablas 

364- 

•  1  P9*« 

UK  301  CoralS6  Tsas 

Arrays  of  Arrays  -  Strings 

365- 

ei  pg». 

UK  DOI  Fortran  Taas 

Largs  Attrlbutas 

366- 

81  pgs. 

UK  DOI  Fortran  Taas 

Underflow 

367- 

82  pgs. 

UK  DOI  Fortran  Taas 

Bxeaptlons 

368- 

82  pq«. 

UK  DOI  Fortran  Taas 

Aliasing 

369- 

81  pgs. 

UK  DOI  Fortran  Taas 

Procedure  Parasatars 

378- 

81  pgs. 

UK  DOI  Fortran  Taas 

Array  Layout  and  paging 

371- 

81  pg«. 

UK  DOI  RTL/2  Taas 

I/O  is  Inadequate 

372- 

88  pgs. 

Mils  Jorgan  Olsson 

Text_I0  Procadura  Nasos 

373- 

88  pgs. 

Nils  Jorgan  Olsson 

Built-in  Queues 

374- 

08  pgs. 

Swon  Tafvalin 

Initiate  with  Arguments 

375- 

88  pgs. 

Svan  Tafvalin 

Waiting  for  Resources 

376- 

88  pgs. 

Svan  Tafvalin 

I/O  Timeouts 

377- 

88  pgs. 

1.  J.  Gallaher 

•Exchange*  Operator 

378- 

81  pgs. 

Burkin Shaw  (IABG) 

Long  Identifiers 

379- 

81  pgs. 

I.  C.  Pyla  (York) 

Real  Type  Attrt  'LARGE,  'BITS,  a* 

388- 

81  pgs. 

I.  C.  Pyla  (York) 

'SIZE  of  Access  Types 

381- 

81  pgs. 

I.  C.  Pyla  (York) 

'SIZE  of  Records  with  Variants. 

382- 

81  pgs. 

I.  C.  Pyla  (York) 

Whan  Clausa  Irregular 

383- 

88  pgs. 

3.  T.  Galkovski  (IBM) 

Integers  as  Pure  Ranges 

384- 

88  pgs. 

Arthur  Sorkin  (SEL) 

Restricted  Private  Ty^a  Inlt. 

385- 

88  pgs. 

Bureau  of  tha  Cansus 

Unsafe  Discriminant  Setting 

386- 

88  pgs. 

Buraau  of  tha  Cansus 

Need  Variable  Length  Strings 

387- 

88  pgs. 

Buraau  of  tha  Cansus 

Access  to  Laternal  Formats 

388- 

88  pgs. 

Buraau  of  tha  Cansus 

Type  Attrlbutas  In  Generics 

104 


389- 

00  PCS. 

W.  9.  Csrson 

Cass  Syntax  Awkward 

390- 

00  PCS. 

Wayaa  Johnson  (IBM) 

Polntsra  to  Ststto  Objaota 

391- 

00  PCS. 

Warns  Johnson  (IBM) 

Binary  Point  Position 

392- 

00  pcs. 

Warns  Johnson  (IBM) 

Prsdsflns  Conaon  Math  Punettona 

393- 

00  pcs. 

Warns  Johnson  (IBM) 

Maks  Tins  an  Intagsr 

394- 

00  PCS. 

Jot  as  Agarharg 

Chsrsetsr  Sat 

395- 

00  PCS. 

Jonas  Agarbarg 

1/0  Fuhotion  Raasa 

396- 

00  PCS. 

Jonas  Agarbarg 

Sincla-Maaory  Orlantatlon 

397- 

00  PCS. 

Arthur  Sorkln  (SSL) 

Allow  gntrtss  in  Salseta 

398- 

00  PCS. 

Williaa  Rvantoff 

Visibility  sad  Osenrtos 

399- 

00  PCS. 

Williaa  grantoff 

Identifying  "other*  gxcaptlons 

400- 

00  ogs. 

(vantoff  6  Rablnowlts 

Provide  Sots 

401- 

00  PCS. 

grantor f  4  Rablnowlts 

•Delta"  Bad  gsyword 

402- 

00  PCS. 

gvantoff  4  Rablnowlts 

Allow  Embedded  Coaaants 

403- 

00  PCS. 

gvantoff  4  Rabtnowtts 

Aoeuraor-Conatrsint  Syntax 

404- 

00  PCS. 

gvantoff  4  Rabtnowtts 

Strings  Inadsquats 

405- 

00  PCS. 

Chrlstopbar  Banrtoh 

Accragsts  Rotation 

406- 

00  PC*. 

Orac  Burns  (ITT) 

Buffar  Tasks:  Rendasvous  Oslagat: 

407- 

00  PCS. 

Orag  Burns  (ITT) 

Task  Psaily  Attrlbuta* 

408- 

00  PCS. 

Harrr  Carl  (Honsrwsll) 

Oarbaga  Collaotton 

409- 

00  pcs. 

Require  Spaolflad  Optlatsatlons 

410- 

D«*. 

Harrr  Carl  (Bonarwall) 

Run  Tibs  Environment 

411- 

00  pcs. 

Harrr  Carl  (Honsrwsll) 

Many  Bodla*  with  Ona  Hans 

412- 

00  PCS. 

Braudaway  4  Louis  (IBM) 

Flxad-polnt  Rapraaantatton 

413- 

00  PC*. 

Warns  Johnson  (IBM) 

Plxsd-polat  Rapraaantatton 

414- 

00  PCS. 

Warns  Jobnson  (IBM) 

Pointing  to  Statle  Objects 

415- 

00  pcs. 

Braudaway  4  Johnson 

Tina 

1 05 


*16- 

02 

PI'- 

A.  J.  Searpeill  ( AFAL) 

Aoesss  Type  Inltlsllsstlon 

*17- 

01 

pcs. 

A.  J.  Soarpelll  l AFAL) 

Aoosss  Types  for  Sasll  Objeots 

*18- 

02 

PCS. 

Richard  Wolff  (WWC) 

Conversion  of  User-Defined  Typss 

*19- 

01 

PCs. 

W.  loos  *  J.  Cross 

Cosponsnt  Rasss  as  Qsnsrlo  Pars 

*20- 

01 

PCS. 

D.  Boldsvorth 

Plzad-Lsncth-Rsault  ’Rap  Dsslrsd 

421- 

01 

PCS. 

C .  Hopper 

Exist  Pradloats  for  Fllos  Desiree 

422- 

01 

PCS. 

Charles  Boksrt 

Tlss  should  bo  Plzsd  or  Intscsr 

*23- 

01 

PCs. 

Charles  Boksrt 

Fixed-Point  Saals  Factors  Dsalrst 

*24- 

01 

PCS. 

Chsrlss  Boksrt 

Haohlns  Cods  Inssrtlona  Clussy 

*25- 

01 

PCS. 

Chsrlss  Boksrt 

Allou  and  ♦  for  Float  Ls: 

*26- 

01 

PCS. 

K.  Boppsr 

Require  Inlt.  (cl van  no  B0_?AL_Et 

427- 

01 

PCS. 

K.  Boppsr 

Priority  on  Entry  Qususs 

*28- 

01 

PCS. 

John  Butohlson 

Anonysoua  Typsa  Laok  Ittrlbutsa 

*29- 

01 

PCS. 

John  Butohlson 

Dynaslo  Length  3pso  for  Aoosas  Tj 

*30- 

01 

PCS. 

Bill  Robinson 

End  or  Fils  sa  Pradloats 

*31- 

01 

PCS. 

Bill  Robinson 

VHP  ■  Function  *  Pracsa 

*32- 

01 

PCS. 

P.  Burklnshsu  (ZABO) 

Multiple  Asslcnssnta 

*33- 

01 

PCS. 

P.  Burklnshsu  (IABO) 

For  Variable  Soops  (Exceptions) 

*3*- 

01 

PCS. 

P.  Burklnshsu  (IABO) 

Collapsed  Elsa's;  Multiple  Bad  If 

*35- 

01 

PC*. 

Ellis  Thosss  (SDL) 

*36- 

01 

PCS. 

Bill  Robinson 

Multiple  Subunits  -  Sans  Bass 

*37- 

01 

PCS. 

Bill  Robinson 

Locloal  Operators'  Prsosdsnos  Ru: 

*38- 

02 

PCS. 

Vllllts  A.  Wbltaksr 

Expression  Evaluation  Order 

*39- 

02 

PCs. 

Wllllas  A.  Vbltsksr 

MOD 

««0- 

02 

PCS. 

Firth  (RMCS) 

Reaove  Belt  Whan 

*«1- 

01 

PCS. 

Brlsn  Wlahasnn 

Entries  Declared  on  Task  Bodies 

4*2- 

00 

PCs. 

Thosss  J.  Whsslsr 

Accept  Syntax 

■W.  W.-'Y  ' 
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443- 

00  pga. 

Tavid  Grles 

And  than  va.  Cand 

444- 

01  pga. 

I.  C.  Pyla 

Bntrlaa  aa  Subprog raas 

445- 

01  pga. 

Mauraan  E.  Gordon 

Raatrlctad  Clauaa  and  Encloaura 

446- 

61  pgs. 

Maureen  E.  Gordon 

(Jaa  Clauaa  Radundant 

447- 

61  pga. 

Mauraan  B.  Gordon 

Ordar  of  Oaclaratlon  Elaboration 

448- 

01  pga. 

Mauraan  B.  Gordon 

Logical  Operators*  Pracadanca 

449- 

01  pgs. 

Mauraan  E.  Gordon 

Allow  Body  Separation  Bvarywhara 

450- 

01  pga. 

Mauraan  E.  Gordon 

Allow  Rafaranca/Copy  Cholea 

451- 

01  pgs. 

Mauraan  B.  Gordon 

Clarify  Unsafe_Converslon 

452- 

01  pga. 

Mauraan  B.  Gordon 

Entry  Call  Tine-Out 

453- 

«i  pga. 

Mauraan  B.  Gordon 

Data  Locking 

454- 

*3  pga. 

Ronald  Brandar  (DEC) 

Ellmlnata/Clarlfy  Environment  Pr£ 

455- 

00  pg«. 

Dan  W.  Scott 

Array  Slicing;  Array  Syntax 

456- 

00  M«. 

Dan  W.  Scott 

Strlnga 

457- 

00  pga. 

Dan  W.  Scott 

Conatant  Record  Coaponanta'  Manat 

458- 

00  pga. 

Dan  W.  Scott 

Dlacrialnanta 

459- 

00  pga. 

Dan  w.  Scott 

Ganartc  Paraaatar  Permutation 

460- 

00  pga. 

Dan  w.  scote 

Raantrancy;  Own 

461- 

00  Pga. 

Dan  W.  Scott 

Hunoroue  Conaant 

462- 

00  pga. 

Dan  W.  Scott 

Rapraaantatlon 

463- 

60  pga. 

Dan  W.  Scott 

Representation  of  Arraya 

464- 

00  pga. 

Dan  W.  Scott 

LRM  Index  Shortcomings 

465- 

00  P9». 

Dav?d  T.  Moora 

Reaunptlve  Exceptions 

466- 

00  pga. 

David  T.  Moora 

Identifying  tnstaneaa  of  Exceptic 

467- 

»•  M«. 

David  T.  Moora 

Loop  Indieaa'  Declaration 

468- 

00  pga. 

Ray  Van  Taasla 

obsolete 

469- 

00  pga. 

I.  C.  Pyla 

'Addraaa  of  an  Overloaded  Subproc 
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*70- 

00  pga. 

I.  C.  Pyl# 

*71- 

00  pga. 

I.  C.  Pyl# 

*72- 

00  pga. 

I.  C.  Pyl# 

*T3- 

00  pga. 

I.  C.  Pyla 

*7*- 

00  pga. 

I.  C.  Pyla 

*75- 

00  pga. 

I.  C.  Pyla 

*76- 

00  pga. 

I.  C.  Pyla 

*77- 

00  pga. 

Dan  W.  Scott 

*78- 

00  pga. 

Dan  W.  Seott 

*79- 

00  pga. 

Dan  W.  Seott 

*80- 

00  pga. 

Dan  W.  Scott 

*81- 

00  pga. 

Dan  W.  Scott 

*82- 

00  pga. 

Dan  W.  Scott 

*83- 

00  pga. 

Dan  W.  Soott 

48*- 

00  pga. 

Dan  W.  Soott 

*85- 

00  pga. 

Dan  W.  Soott 

*86- 

00  pga. 

Dan  W.  Soott 

*87- 

00  pga. 

Dan  W.  Soott 

488- 

00  pga. 

Dan  W.  Soott 

*89- 

00  pga. 

Dan  W.  Soott 

*90- 

00  pga. 

Dan  W.  Soott 

*91- 

00  pga. 

Dan  W.  Soott 

*92- 

00  pga. 

ids  Group  Tokyo 

*93- 

00  pga. 

Ada  Group  Tokyo 

*9*- 

00  pga. 

Ada  Group  Tokyo 

*95- 

00  pga. 

Ada  Group  Tokyo 

*96- 

00  pga. 

Ada  Group  Tokyo 

Typ#  of  'Delta  and  '3uU? 

What  art  'Syataa'  and  'Option' 7 
Priority  aa  Typ#  Raao 
Qanarlo  Subprog  aa  Oanario  Para 
Piald  Raaea,  ato.  aa  Oanario  Par 
Exceptions  in  Oanario  Packages 
Typaa  aa  array  Bound* 

Access  Typaa:  allocation,  Init. 
iooaaa  Typo  Initialisation 
'Praa'  Operation 
Dereferencing  Conaldered  Cluaay 
.all  of  array* 

"*"  and  in  Identifiers 

Qualification  Syntax  Disliked 
'laatrleted ' ;  Block*'  Vlaiblllty 
Constant* 

Typaa  Deriead  froa  Priests  Typaa 
Nultldaaanalonal  array* 

Scop*  naeaa 
[...]  in  Hats-Syntsx 
Salaotad  Coaponant  Syntax 
Corrlgandua  *.1.3 
What  la  Syataa? 

"string  t"  and  "string  l  string" 
String*  of  Length  One 
Hon-Aocaaa  tnooaplete  Type  Daol. 
Is  a  Subty  Coapatlbl*  w/lts  Baa* 


•au-a  e'l 


fe*£ 


*97-  00  pga. 

*98-  00  pga. 

*99-  00  pga. 

500-  00  pga. 

501-  00  pga. 

502-  00  pga. 

503-  00  pga. 

50*-  00  pga. 

505-  00  pga. 

506-  00  pga. 

507-  00  pga. 

508-  00  pga. 

509-  00  pga. 

510-  00  pgu. 

511-  00  pga. 

512-  00  pga. 

513-  00  pga. 

51*-  00  pga. 

515-  00  pga. 

516-  00  pga. 

517-  00  pga. 

518-  00  pga. 

519-  00  pga. 

520-  00  pga. 

521-  00  pga. 

522-  00  pga. 

00  pga. 


Ada  Group  Tokyo 
Ada  Oroup  Tokyo 
Ada  Oroup  Tokyo 
Ada  Oroup  Tokyo 
Ada  Oroup  Tokyo 
Ada  Oroup  Tokyo 
Ada  Oroup  Tokyo 
Ada  Oroup  Tokyo 
Ada  Oroup  Tokyo 
Ada  Oroup  Tokyo 
Ada  Oroup  Tokyo 
Ada  Jroup  Tokyo 
Ada  Group  Tokyo 
Ada  Oroup  Tokyo 
Ada  Oroup  Tokyo 
Ada  Oroup  Tokyo 
Ada  Oroup  Tokyo 
Ada  Group  Tokyo 
Ada  Oroup  Tokyo 
Ada  Oroup  Tokyo 
Ada  Oroup  Tokyo 
Ada  Oroup  Tokyo 
Ada  Oroup  Tokyo 
Ada  Oroup  Tokyo 
Ada  Oroup  Tokyo 
Ada  Oroup  Tokyo 
Ada  Oroup  Tokyo 


Allow  Ialt.  for  Hon-Reeord  Typo. 
Xahorltaaaa  of  Subprg  by  Derlvat 
Syntax  of  Charaoter_Llteral? 
Allow  3hort_Xtttagor  *  Integer 
Compatibility  among  lot,  Short.: 
What  arm  floating  6  Flxad  point 
Clarify  'amall  and  'largo 
'amall  and  'larga  of  Flxad  Poln- 
Kaka  I  In  'Length  (I)  Statlo 
What  la  tha  Typa  of  Subarraya? 
Typo  of  Ranga  Componanta  In  For 
Bounda  of  Oynamla  Arrays 
la  *2  I  Othara  a>  oa  Lagal7 
Allow  Only  Ona  Dynamic  Arr  par  ' 
What  la  eomplata  Raaord  Assignat 
Arrays  with  Xndsk  Typa  Intagar 
Multl-dlm  Arr  am  Arrays  of  Arra; 
What  la  a  Stmplo  Hama? 

Ambiguity  of  Subprg  as  Typa  Att 
Doflno.Typa  Compatibility  for  0- 
Logical  Opor  Arrays  of  Dlff  Bout 
Daflns  Raault  Aoouraoy  Fraolaal 
Is  Xntagar**0  Allowed? 

Improve  Typa  Qualification  Exam 
Daflna  lot  (Real)  Unambiguously 
Clarify  Statlo  expressions 
Compatibility  of  Nultl-Qlm  Arra 


523 
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52*- 

00  pgs. 

Ada  Group  Tokyo 

525- 

02  pgs. 

Maureen  E.  Gordon 

|  i 

526- 

00  pgs. 

Ada  Group  Tokyo 

527- 

00  pgs. 

Ada  Group  Tokyo 

528- 

00  pgs. 

Ada  Group  Tokyo 

529- 

00  pgs. 

Ada  Group  Tokyo 

530- 

00  pgs. 

Ada  Group  Tokyo 

53'- 

oo  pgs. 

Ada  Group  Tokyo 

532- 

00  pgs. 

Ada  Group  Tokyo 

533- 

00  pgs. 

Ada  Group  Tokyo 

r 

53»- 

00  pgs. 

Ada  Group  Tokyo 

535- 

00  pgs. 

Ada  Group  Tokyo 

.  •  536- 

00  pgs. 

Ada  Group  Tokyo 

\ 

■'  A  53T- 

00  pgs. 

Ada  Group  Tokyo 

538- 

00  pgs. 

Ada  Group  Tokyo 

539- 

00  pgs. 

Ada  Group  Tokyo 

5*0- 

00  pgs. 

Ada  Group  Tokyo 

5*1- 

00  pgs. 

Ad*  Group  Tokyo 

5*2- 

00  pgs. 

Ada  Group  Tokyo 

5*3- 

00  Dgs. 

Ada  Group  Tokyo 

5*«- 

00  pgs. 

Ada  Group  Tokyo 

5*5- 

00  pgs. 

Ada  Group  Tokyo 

5*6- 

00  pgs. 

Ada  Group  Tokyo 

5*7- 

00  pgs. 

Ada  Group  Tokyo 

5*8- 

00  pgs. 

Ada  Group  Tokyo 

5*9- 

00  pgs. 

Ada  Group  Tokyo 

550- 

00  pgs. 

Ada  Group  Tokyo 

Uhat  l*  a  Qualifla*  Variable! 

8*P* •  -1“  e**i«p«tl° 

Exception  Propagation 
Disallow  Overloading  of  Gentries 
Intar-Ovarload  of  G*n*rU  4  Subp 
Generic  Overloading 
Improve  E*p/U«r*c»t*  Syntax 
Clarify  "Integer*  In  Appendix  A 
frt|  Snvlr . .  Xnolud*  Ch*B«*  Sea. 
Clarify  Optimise  Pragma 
Clarify  Page  Pragma 
Clarify  UJt  Pragma 
Clarify  Inelud*  Pragma 
!*orove  L*M  Ind*x 

'-cessed  Object*  Paaaad  "i 

Define  Label  »F*ep  End  Loop 
Syntax  of  Hodula*  Ambiguous 
Are  D* faults  Allowed  for  CutUnC 
Can  an  Out  Poraal  b.  Bead  in  Bod 
Do  Cnstr  on  Actual  Apply  to  fora 
Can  Becurslv*  Subprogram*  b*  Ini 
Darin.  Identity  of  Signatures 
Cheek  Fune.  Ho_Val_Err  Statical i 
Ar*  Defaults  Part  of  Signatures! 
Label  Scop* 

Nam*  Space  of  Labels 
5\»rlfy  overloading  **•  Hiding 
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551- 

00  p(S. 

Ada  Group  Tokyo 

Clarify  Seopa  and  Visibility 

552- 

00  pcs. 

Ada  Group  Tokyo 

Contsnts  of  Visibility  Lists 

553- 

00  pcs. 

Ada  Group  Tokyo 

Oss*  Conflict  Rais 

55*- 

00  pcs. 

Ada  Group  Tokyo 

What  is  tts  Bad  Idsnt.  in  Accepts 

555- 

00  PC*. 

Ada  Group  Tokyo 

Explain  Tasking  Bxcspt.  in  Task  E 

556- 

00  PCS. 

Ada  Croup  Tokyo 

What  is  a  Frograa  Library? 

557- 

00  pgs. 

Ada  Group  Tokyo 

Osfins  Predefined  Exoept.  Precise 

558- 

00  PCS. 

Ada  Group  Tokyo 

Croas-Rsfsrsncs  Tasklng_JJrrcr 

559- 

00  DCS. 

Ada  Group  Tokyo 

Lst  "Other"  Znclud  Out  of  Scop*  E 

560- 

00  PCS. 

Japan  Joint  Systsn? 

Iabsddsd  Consents  Dsairsd 

561- 

00  pgs. 

Japan  Joint  Systsas 

Partial  Attr  Inheritance  by  Subt) 

562- 

00  pgs. 

Japan  Joint  Systsas 

Derived  Aecsas  Typss 

553- 

00  pgs. 

Japan  Joint  Systsas 

Subtyplcg  and  Recursive  Typss 

564- 

00  pgs. 

Japan  Joint  Systsas 

Expr.  Evaluation  Ordsr  Over-Re str 

565- 

00  pgs. 

Japan  Joint  Systsas 

Corrlgsndua  4.5.2 

566- 

00  pgs. 

Japan  Joint  Systsas 

Prs*  Opsration  Qsslrsd 

567- 

00  pgs. 

Japan  Joint  Systsa. 

Hultldla.  Array*  as  Arrays  of  Art 

568- 

00  pgs. 

Japan  Joint  Systsan 

Osfault  Positional  Paras.  Dasirsc 

569- 

00  pgs. 

Japan  Joint  Systsas 

Labsl  Seop* 

570- 

00  pgs. 

Japan  Joint  Systsas 

Selective  Iaport  Dssirsd 

571- 

00  pgs. 

Japan  Joint  Systsas 

Do  fins  Labal  aftsr  End 

572- 

00  pgs. 

Japan  Joint  Systsas 

Clarify  Initiation 

573- 

00  pgs. 

Japan  Joint  Systsas 

Corrlgsndua  10. t 

574- 

00  pgs. 

Japan  Joint  Systsas 

Spsolfying  Enclosing  Unit  of  Subt 

575- 

00  pgs. 

Japan  Joint  Systsas 

Opts  Discussions  batons  in  Ratlor 

576- 

00  pgs. 

Japan  Joint  Systsas 

Dlslgnator  as  Gansric  Paraastsr 

577- 

00  pgs. 

Japan  Joint  Systsas 

Type  of  Length  Expression 

I 


578- 

00 

PS* 

579- 

00 

Pg» 

580- 

00 

Pga 

581- 

00 

PCS 

582- 

00 

PS* 

583- 

00 

PS* 

58t- 

00 

pg* 

585- 

00 

PS* 

586- 

00 

PS* 

587- 

00 

PS* 

588- 

00 

PS* 

589- 

00 

PS* 

590- 

00 

PS* 

591- 

00 

PS* 

592- 

00 

PS* 

593- 

00 

PS* 

591- 

00 

PS* 

595- 

00 

PS* 

596- 

00 

PS* 

597- 

00 

PS* 

598- 

00 

PS* 

599- 

00 

PS* 

600- 

00 

PS* 

601- 

00 

PS* 

602- 

00 

PS* 

603- 

00 

PS* 

60t- 

00 

PS* 

-  til  - 

Japan  Joint  Syataaa  Iaprove  Other-Language  Intarfaoa 

Japan  Joint  Syatea*  Iaprove  1/0:  Teralnala,  Reoorda 

Japan  Joint  Syateaa  Corrigendua  It. 3.2 

Japan  Joint  Syateaa  Clarify  Daflnltlon  of  tllaaing 

Japan  Joint  Syataaa  Overloading  Dlaaablguatlon 

Japan  Joint  Syataaa  Syntat  Irragulantlaa 

Japan  Joint  Syataaa  Pragaaa  ato.  ire  Not  Language  laa 

tklra  Nagaahlaa  (CMO)  Hake  Plxed-Polnt  Delta  Bxaot 

tklra  Nagaahlaa  (CHO)  Uaer-Deflned  taalgnaant;  VRPa  on 

tklra  Nagaahlaa  (CHO)  tllow  Entry  Overloading 

tklra  Nagaahlaa  (CMO)  tllow  Deferred  Conat  aa  Dlaerla  C 

tklra  Nagaahlaa  (CHO)  Provide  Dlaerla  Cnatr  In  tllooato 

Bjarne  Daekar  (Sweden)  Defining  tooept/Call  Relatlona  at 

Bjarne  Decker  (Sweden)  No-Halt  Meaaage  Paaa'lnt  Deairad 

Bjarne  Daekar  (Sweden)  Dynaalo  Taak  Identification  Daalr 

Thoaaa  J.  Pennello  Subtypea  aa  Rangea 

Thoaaa  J.  Pennello  idd  Uaer-Deflnad  Operatora 

Thoaaa  J.  Pennello  Conditional  Expreaalona  Valuable 

Thoaaa  J.  Pennello  Iteratora  Dealred 

Thoaaa  J.  Pennello  ■Reatrleted"  Overloaded 

Thoaaa  J.  Pennello  "New*  Overloaded 

Thoaaa  J.  Pennello  Baae-Type  Function 

Thoaaa  J.  Pennello  Onordered  Enuaeratlona  Dealred 


Thoaaa  J.  Pennello 
Thoaaa  J.  Pennello 
Thoaaa  J.  Pennello 


■Range*  Overloaded 

Dlatlngulah  Loop  froa  Goto  Labela 

*Ia*  Overloaded 

Separate  Vialblllty  froa  Iaportat 


Thoaaa  J.  Pennello 


605- 

00 

PC* 

606- 

00 

PC* 

607- 

00 

PC* 

608- 

00 

PCS 

1 

O' 

o 

SO 

00 

PCS 

6  10- 

00 

PCS 

611- 

00 

PCS 

612- 

00 

PCS 

6  13- 

00 

PCS 

6  14- 

00 

PCS 

615- 

00 

PCS 

616- 

00 

PCS 

617- 

00 

PCS 

6  1 8- 

00 

PCS 

619- 

00 

pgs 

620- 

00 

pgs 

621- 

00 

PCS 

622- 

00 

Pgs 

623- 

00 

Pgs 

624- 

00 

PCS 

625- 

00 

PCS 

626- 

00 

PCS 

627- 

00 

PCS 

628- 

00 

pgs 

629- 

00 

PC* 

630- 

00 

PC* 

631- 

00 

Pgs. 

J.F.H.  Hinkler 
Richard  J.  Merer* 
Richard  J.  Meyer* 
Richard  J.  Meyer* 
Rlohard  J.  Meyers 
Richard  J.  Meyers 
Richard  J.  Meyers 
Richard  J.  Meyers 
Ray  Van  Taasle 
Ray  Van  Taasle 
(Uni*.  of  Copenhagen) 
(Uni*.  of  Copenhagen) 
(Uni*,  of  Copenhagen) 
(Uni*,  of  Copenhagen) 
(Uni*,  of  Copenhagen) 
(Uni*,  of  Copenhagen) 
(Uni*,  of  Copenhagen) 
(Unlv.  of  Copenhagen) 
(Uni*,  of  Copenhagen) 
(Unlv.  of  Copenhagen) 
(Uni*,  of  Copenhagen) 
Frank  Ue  Reaer 
Frank  De  Reaer 
Frank  De  Reaer 
Frank  De  Reaer 
Frank  De  Reaer 


Syntax  Coaaents 
Loop  A  Goto  Labels 
Overloading  "Men* 

AMD  TRIM  and  OR  ELSE  Anywhere 
State  Subunit's  Identity 
Asynchronous  Entries 
Restricted  Overload*! 

Types  as  Olsoret*  Ranges 
Unsigned  Integer  Type 
Increaenting  etc  (":»»") 
Distinguish  Types  froa  Subtypes 
Define  Label  after  End  Stateaent 
Label  Scope 

Syntax  of  Subprograa  Attributes 
Iaprove  Identification  of  Subprg: 
Semantics  of  Task  Failure 
Seaantlcs  of  Abort 
Separate  Coapilation 
Allow  Functional  Arguaents 
Syntax  Inooaplete  and  Aabiguous 
Regularise  Declaration  Syntax 
Allow  Static  Expressions  In  Frags 
Oper  Designators;  User-Coined  Ope 
Tighten  Op  Syntax 
Overloading  of  Keywords 
Regularise  Declaration  Syntax  (LA 
Freer  Flaceaent  of  Rep.  Specs. 


Frank  De  : eaer 
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632- 

00 

PC*. 

Frank 

Da 

Raaar 

Dlatlnfulsh  Loop  froa  Goto  Labals 

633- 

00 

PC*. 

Frank 

Da 

Raaar 

Raatruetura  Dnlt  Haadar  Syntax 

63*- 

00 

PC*- 

Frank 

Da 

Raaar 

Union  Typaa;  Itarators 

635- 

00 

PCS. 

Frank 

Da 

Raaar 

Conditional  Bxpraaslona  Valuabla 

636- 

00 

PC*. 

Frank 

Da 

Raaar 

Subtypos  as  Rangas 

637- 

00 

PC*. 

Frank 

Da 

Raaar 

Cap.  Non-Taralnals;  *...*  Hatasyn 

638- 

00 

PC*. 

Frank 

Da 

Raaar 

Rastrlotlva  Clauaaa:  "That* 

639- 

00 

PC*. 

Frank 

Da 

Raaar 

Laxleal  Graaaar 

640- 

00 

PC*. 

Frank 

Da 

Raaar 

Raaora  Radaclaratlon  Rastrletlons 

6*1- 

06 

PC*. 

Goodanoufh  (SofTtch) 

Optlalxatlon  and  Excaptions 

6*2- 

0* 

PC*. 

Firth 

( BMCS ) 

AND  THEN  and  OR  ELSE 

6*3- 

02 

PC*. 

Goodanoufh  (SofTaeh) 

Oalttad  Excaptions? 

6*4- 

02 

PC*. 

Banjaaln 

M.  Brosfol 

Saaantle  Chocking  of  Ganarle  Bodi 

6*5- 

0* 

PC*. 

Goodanoufh  (SofTaeh) 

Rafaraneaa  to  Unalaboratad  Objaet 

6*6- 

07 

PC*. 

Goodanoufh  (SofTaeh) 

Efficient  Machine  Coda  Insertions 

6*7- 

01 

PC*. 

Belmont  (Intermetrics) 

Type  In  Range  Constraints 

6*8- 

01 

PC*. 

William  * 

.  Whltakar 

Order  of  Evaluation 

6*9- 

01 

PC*. 

W.  Paul  Sbarar 

Allow  Overlapping  Slice  Asalgnaen 

650- 

w  - 

PC*. 

Wllllaa  A 

.  Whltakar 

Hoad  for  a  FREQUENCY  Pragaa 

651 

00 

PC*. 

Foldaaaon 

(SAAB-SCANIA) 

Delay  and  Cyolio  Programs 

652 

00 

PCS. 

Douflaa  W 

.  Jonaa 

Parameters  and  Tasking 

COM  t 

SIZE 

SOURCE 

SUBJECT 

001- 

01  pgs. 

Nagle  (Ford  Aaro.) 

Integer  Seaantles 

002 

01  pgs. 

Goodanoufh 

LIR .003 

003 

01  pgs. 

Goodenough 

EVR.002 

1  14 


004- 

08  pgs. 

Firth 

005- 

01  Pgs. 

Holdworth 

006- 

01  pgs. 

Balaont 

007- 

01  pgs. 

Bvlaont 

008- 

04  pgs. 

Qoodanough 

009- 

01  pgs. 

Qlllaann 

010- 

05  pga. 

Coapton 

011- 

02  pgs. 

Balx 

012- 

01  pga. 

Qlllaann 

013- 

01  pgs. 

Garaan  MOD 

014- 

I64pga. 

Habaraann  at 

015- 

05  pgs. 

Firth 

016- 

02  pgs. 

M.  Ban-Arl 

017- 

01  Pgs. 

3.  LJungkuist 

018- 

03  Pgs. 

E.  M.  Qrsana 

019- 

01  pgs. 

D.  T.  Moor* 

020- 

16  pgs. 

Robert  Milne 

021- 

03  pgs. 

MacLaren 

022- 

13  Pgs. 

HI 1  finger 

023- 

03  pgs. 

Firth 

024- 

1 1  pgs . 

Firth 

025- 

01  pgs. 

Firth 

026- 

01  pgs. 

Brownlie 

027- 

02  pgs. 

Firth 

028- 

00  Pf.A. 

C.  Tandow 

029- 

00  pgs. 

0.  T.  Moore 

030- 

00  pgs. 

J.  D.  Cox 

Coaaents  oe  DCI  l-S  (TT> 
Standard  Portable  Language 
Structure  or  NODULES 
Soparata  Coepllatlon 
Rotas,  Aug. 6  Revise  Moating 
Ada  Syntax 
16  OlToraa  Feints 
Revised  DCI. 003 
Conatant  arrays  and  raeorda 
LCX.003 

al.  Livers*  Points,  GAIDALF 

Paraaatar  Panning 
Block* ,  Short  Circuit* 

Sat  Typo 

General  Cooaantx 

' ADDRESS  Attrlbuta/Reglstera 

0*n*ral  Coaoaata 

Physical  latarfaeaa 

Coaaant*  on  PCI. Q03 

31de-*f facts 

Minutes  of  Sapt.  Moating 
Draft  on  Sida-Kffoets 
Tasking 

Though*.*  on  Ada  TAR 
Task/Modulo  Distinction 
Indexing  into  loeorda 
Proposed  tnhaneaaanta 


S£tvr.ts®efcU;,  v 


I 

‘f 
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031- 

00  pgs. 

J.  Byrd 

032- 

00  pgs. 

R.  D.  Johnson 

033- 

00  pgs. 

R.  D.  Johnson 

034- 

00  pgs. 

M.  T.  Devlin 

035- 

01  pgs. 

Firth 

036- 

07*  pgs. 

Ooodenough 

037- 

02  pgs. 

MacLaren 

038- 

01  pgs. 

Ooodenough 

039- 

01  pgs. 

Davis 

040- 

08  pgs. 

Evans 

041- 

03  Pgs. 

Hi  If lngar 

042- 

03  pgs. 

MacLaren 

043- 

02  pgs. 

Hilf inger 

044- 

07  pgs. 

MacLaren 

045- 

00  pgs. 

Shulaan 

046- 

00  pgs. 

Cooper 

047- 

00  pgs. 

Archer 

048- 

02  pgs. 

Paul  Hi  If inger 

049- 

00  pgs. 

Mark  Hapner 

050- 

00  pgs. 

Mark  Hapner 

051- 

00  pgs. 

Mark  Hapner 

052- 

00  pgs. 

Mark  Hapner 

053- 

00  pgs. 

Mark  Hapner 

054- 

00  pgs. 

Msrk  Hapner 

055- 

00  pgs. 

Kenneth  Dickey 

056- 

00  pgs. 

J.  K.  Reid 

057- 

00  pgs. 

Rudolf  Marty 

!. 

I 

7- 

* 


Negative  Nuabers 

Macro  Facility  Maadad 
FREE  Maadad 

Siaplif icatlona 
Coaaanta  on  v3  OCR' a 
Coaaants  on  v3  DCR'a 
Coaaanta  on  v3  OCR' a 
Coaaanta  on  v4  DCR’a 
Raaponae  to  COM. 029 
Ada  Tasking 
Coaaanta  on  COM. 040 
Interface  Concepts 
Coaaanta  on  COM. 042 
Interface  Costa 
Coaaanta  on  Reference  Manual 
Binary  File  10  In  Ada 
ADA  Subset  Definition 
Coaaants  on  Interface  Coats 
Parssetar  Binding  Seaentlcs 
Urge  Applications 
Coaaent  on  DCR.002v3 
Reentrancy 

Coapound  Type  Constraints 
Tasking 

Square  Brackets  for  Subscripts 
Intrinsic  Functions  for  Floats 
Padding  on  String  Aasignaent 


—Mn  iMfc 
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058- 

01  pcs. 

Jsao  E.  Saaaat 

Naad  for  Baal  Tlaa  Clock 

059- 

09  PC*. 

Richard  L.  Sobvartx 

060- 

00  pcs. 

Sarsfiao  Aaoroao 

BCL's  review  of  Ada. 

061- 

01  pc*. 

Hobart  Firth 

Coaaaat  on  LIE. 203 

062- 

02  pcs. 

NADC-ADA 

Static  Variables 

• 

o 

02  pcs. 

Hobart  Firth 

Ada  Construction  Kit 

06*- 

01  pcs. 

La*  Mac La ran 

Flxad  Point  Representation 

065- 

01  pc*. 

Lee  HocLaren 

Dynaale  Prioritise 

066- 

01  pcs- 

Paul  Hllflncer 

Foralcn  Prooadura  Paraaatars 

067- 

07  pcs. 

Hobart  Firth 

Ada  ‘Blackboard’  Issues 

068- 

02  pcs. 

Hark  Davis 

Naaad  Parsaatsrs  and  Overloading 

069- 

01  pcs. 

Hark  Davis 

Slda-affaots  and  Functionality 

070- 

00  pcs. 

A.  D.  Hill 

1/0;  Exoaptlons;  ate. 

071- 

00  PCS. 

H.  1.  Shan 

Suspension;  Scheduling;  Goto 

072- 

00  PCS. 

Franelseo  Oyarxun 

Prlv.  part;  Oarafar;  Ineoaplata  t 

073- 

00  PCS. 

Jaaas  A.  Haris 

Listings;  Pragaas 

07*- 

00  PC*. 

Alexander  Goodall 

Saleot  Stataaant 

075- 

00  PCS. 

0.  G.  Elliott 

Ruabars;  Extensibility;  ato. 

076- 

00  PCS. 

Nall  Parksr 

Fora  of  Hanual;  Syntax;  ate. 

077- 

00  PCS. 

Thoaas  H.  Aaoth 

Repeat  Until  and  Bhila  Do 

078- 

00  PCS. 

A.  Sllbersohatx 

Aecepta  vs.  •Parts* 

079- 

00  PCS. 

C.  H.  Lindsay 

Neologises;  Various  Points 

080- 

00  PCS. 

W .  R.  LaLonda 

Strings 

081- 

00  pcs. 

( IABG ) 

Systaas  Prograaaing:  Various  Poln 

082- 

00  PCS. 

Laurence  J.  GaHahar 

Scheduling;  Iteration 

083- 

00  PCS. 

Hayaond  T.  Bouta 

Arbitrary  Rastrle:  Various  Points 

08*- 

10  PCS. 

Laa  HaoLaran  (Boainc) 

Objaot-Orlantad  Synchronisation 

1 1T  - 


089- 

03  PC*- 

Milllaa  Vhltaker 

Pascal  Standarda  Haatln* 

086- 

01  PS*- 

HaoLaran 

Malting  at  Soopa  Bait 

087- 

01  PS*- 

MaeLaren 

Mo  Taakins_Brrors  in  Servers 

088- 

00  PS*- 

(Uni*,  of  Tokyo) 

Sir*  Cxaaplaa  of  Patholosia* 

089- 

06  ps*- 

MaeLaren 

Rntry  Faailioa  *».  Task  Object* 

090- 

00  ps*- 

Extandad  Randasvoua 

091- 

00  ps*- 

Dr.  Meuaann  (Germany) 

Telegraa  Coaaunloatlon 

092- 

00  PS*- 

Toodor  lua  (Ruaania) 

Saaantle  Foraalization 

093- 

00  PS*- 

(Finland) 

Various  Points 

096- 

00  PS*- 

indraw  irblastar 

Buaan  Factors  Rapo.'t 

099- 

00  PS*. 

Pater  Hall la 

Literals  of  Usar-Dafinad  Typa 

096- 

00  PS*- 

(Garasny) 

Elsa  Syntax  Error-Prona 

097- 

00  PS*- 

W.  R.  LaLonda 

Strings 

098- 

00  pss. 

Thonaa  i.  Marolniale 

Paraanant  Data  St-uoturaa  ato. 

099- 

00  PS*- 

i.  K.  Chandlar 

Constant  Graphs 

100- 

03  PS»- 

Firth  (XMCS) 

Raourslon  is  Effloiant 

101- 

02  ps*- 

Firth  ( RMCS ) 

Ovarloadlns 

102- 

06  PS*. 

Firth  (RMCS) 

Low  Laval  Tasklns 

103 

00  PCS. 

R.  Sobwarts  (SRI) 

irtifiolal  Intalllganc*  ipplioati 

106 

00  PS*. 

G.  Bas*  (L  M  Erloaaon) 

Gana-allxatlon  of  Tssklns 

105 

00  ps*- 

Folkaaaon  (SiiB-SCiMIi) 

Cyclaa:  Daisy  and  'Clock 

106 

00  pss. 

J.  Welah  k  i.  Lister 

Tasking:  CCSP  and  DPS 

107 

00  PS*- 

(BBS  Inc.) 

Task  Efficiency  and  Multlproeaasl 

108 

02  ps*. 

Da*ia  Stevenson 

Fairness  and  tha  H-M  Technique 

109 

11  PS*. 

(Intal  Corp.) 

Extensions 

1 10 

00  PS*. 

(Uni*,  of  Copanhasan) 

Coaaants  on  Frallalnary  ids 
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POS  » 

size 

SOURCE 

SUBJECT 

•01 

1  pgs. 

UK  MOO 

Interrupt  Handling 

•02 

3  Pgs. 

UK  MOD 

Modern  Architectures 

M3 

•  1  M* 

firth  (MODI 

Side  Effects  end  Optimization 

OCR  • 

SIZE 

SUBJECT 

001v4 

01  pgs. 

Parameter  Binding  Semantics 

002v4 

01  pgs. 

Parameter  Passing  Conventions 

•03v4 

02  pgs. 

Physical  Interfaces 

M4v3 

01  pgs- 

Array  Slice  Assignment 

M5v3 

01  pgs. 

Exceptions  In  Declarations 

M6v3 

01  pgs. 

Real  Time  Clock 

•07w3 

02  pgs. 

Side-Effects  and  functionality 

•  08v4 

•2  pgs. 

Type  Compostlon 

OPA  » 

SIZE 

SOURCE 

SUBJECT 

001 

1  PM- 

Design  Team 

Transfer  Statements 

002 

i  pg«- 

Design  Team 

Garbage  Collection 

003 

i  pm- 

Design  Team 

Composite  Type  Equality 

•04 

i  pgs- 

Design  Team 

Restricted  Types 

00S 

1  PM- 

Design  Team 

Access  Variable  Initialization 

006 

1  PM  • 

Design  Team 

Access  Type**  Allocators 

007 

1  pgs. 

Design  Team 

Spin  Locks,  etc. 

•08 

1  pgs. 

Design  Team 

functions,  VHP's 

\ 


119 


999 

1  P9*- 

Design  Teas 

Cuaulattve  Processing  Tlae 

919 

1  PS*  • 

Design  Tan 

Type  TIME 

•11 

1  PS*- 

Design  Teaa 

•  12 

1  PS*- 

Design  Ten 

Exception  Handler 

•  13 

1  pgs. 

Design  Ten 

Array  Aggregates 

014 

1  pgs. 

Design  Tea* 

Mull  String 

•  15 

1  PC*- 

Design  Toaa 

HO_VALUE_ERROR 

016 

1  PS*- 

Design  Tea* 

Compilation  Unit  Naalng 

017 

1  PS*- 

Design  Ten 

Constant  Record  Coaponents 

018 

1  PS«- 

Design  Ten 

Syntaxt  [naae.ldealgnator 

019 

1  pgs. 

Design  Teaa 

Task  Initiation 

020 

1  PS*- 

Design  Teaa 

Task  Procedures 

APPENDIX  G 


TER  TOPICS,  SUMMARIES,  AMD  EXTRACTS 


laaica  mntianM  la  lit  a««r» 


ChMBfr  1 

Add:  Lancuac*  subsets:  25 

Chance:  Make  declaration  syntax  aora  unlfons:  30 
Zaprove  syntax:  * 

Require  blocks  ratbar  than  sequence  of  stataaants:  30 


Chanter  2 

Add:  Abbreviations  far  keywords:  3.  30 

Zabeaded  to— ants:  30 >  >2 
Altarnata  cnaraetar  sat  support:  13 
Sit  string  constants:  13.  *1 .  44,  Si,  55 
Secuid:  Easaa  other  than  2,  6,  10,  and  16:  16 

Identifiers 

Chanfa:  hake  hcn-slcnif leant:  30,  *& 

like:  In  laantlflara:  15 

Lent  Identifiers:  19,  37,  "5 
Second:  Significance  of  In  tokens:  7 


Chantar  S 

Add:  Serines:  25.  35.  38,  *5.  55,  61,  63,  72 

Sit  handllne:  26,  71,  77 
function  as  data:  7 
Multi-level  structures:  3 
Reference  variables:  7,  15,  30 
Slaula  classes:  7 

Static  allocation  of  access  objects:  13 
Unsafe  pointers:  l<t 

Variable  declarations  after  local  preera*  bodies:  64 
Stacie  variables:  64 
Chance:  *•>*  has  two  seen Ire  a:  15.  30 

Ranees  sbeuld  not  nave  to  be  ctntleuoua:  30 
Delta  la  poor  keyword:  15 
Expressions  In  ranee  conscralatsil):  0 
Require  specification  of  aaxiaun  size  of  atrlnes:  2 
Store  aatnoes  by  col  ion:  '0 
Types  too  restrictive:  15 
Allow  ancnyacus  types  in  record  fields:  26 
Use  structure  equivalence  for  arrays:  30 
guaranteed  cne-step  conversion  between  derived  types: 
like:  Aeerefate  syntax: 

Accretates:  15,  «0 
Arrays:  :• 

Er.uneratlon  types:  7,  34.  35,  37.  36,  5e,  00,  75,  co 
Derived  types:  36 

Machine- independent  cits  definition:  2 
Overloading:  2,  7  ,  35,  37,  »2,  el 


Record  syntax:  19 

Record  variant  tea  entice:  29 

Initialization  In  decleretione:  06 

Strong  typing :  2.  3.  10,  16,  1b,  26,  29.  31.  “6.  <*b,  50,  52.  5*.  5b.  61.  62.  63. 

71,  72,  73.  77.  60.  66 
Variant  arrays  In  record a:  86 
Arrays  with  mapeclfled  Index  range:  66 
Type  eonatralnta :  1,  20,  69 
Uaer-deflned  typea:  5,  17,  26 
Scope  (or  aeceaa  typea:  29 
Redixw:  Sub  typea:  o7 

Either  auotypea  or  earned  typea:  19 

Derived  typea:  29 

Saaed  ocaponanta  in  aggregates:  25 

Numbers 

Add:  lapliclt  conversion  at  nuaerlc  typea  (when  no  loaa  ot  precision):  30 

Chang*:  Fixed-point  delta  should  be  exact:  27,  26 
Lika:  Precision  specification:  1j 


Chanter  6 

Add:  Conditional  expressions:  7,  2b,  30 

Multiple  assignments:  -0 

Method  of  expressing  parallaliaa  la  expression  evaluation:  21 
'Free'  operation:  29,  69 
Standard  built- in  aath  library:  19 
Standard  Builtln  array  operations:  <6,  19 
Change:  Accurate  fixed  point  arithmetic  (specification,  coercion::  6,  o5.  sd 
Define  aathematlcal  properties  of  usar-oeflned  operators:  1 
More  control  over  allocation:  13,  15 
Qualified  expression  syntax:  1: 

Time  should  not  be  floating  point:  19,  ob 

User  type  names  mould  be  overloaoabl*  aa  conversion  functions:  bp 
Like:  Attributes:  20,  21,  29 

Expression  structure;  19 
Array  slicing:  29,  at 
bo  automatic  type  conversion:  lb 
R sound :  Allocators  for  access  types:  1 
Array  slicing:  io 


Ado:  Compound  statements:  7  . 

Sicca  exits:  63 

Exit  from  named  block:  ;0 

Change:  Remove  aanoatcry  semicolon  before  end,  elslf,  etc.:' ;0 
Allow  sizing  of  "ana  then*  and  "or  *16*":  26 
Allow  VHP’s  as  conditions:  30 

Overloading  rules  too  complicates  w.r.t.  parameters:  :6 


Redund:  Elaif :  16. 

Function  call  syntax:  10,  06 

layuord  perMetar-assoolatlon  syntax  atd.):  7,  19,  17 

Assert:  30,  5*.  6s 

Labels  and  gotas:  1,  »,  30,  a* 

Short  circuit  conditions:  16,  5*,  ad 

Loops 

Add:  Sort  loop  constructs:  13,  16.  17,  a7 

Chanda :  lisa  *ac"  not  *loop*  as  kayeoro:  19 
Lika:  Structured  .n  i  |rf  1  n|  constructs:  1,  5;  10,  13 

Reduaa:  Exit  uhen:  a,  5** ,  69 
exit :  * 


Chanter  6 

Idd:  Functional  srguaer.es:  a,  10,  11,  16,  *0,  is,  o9 

Intermixed  declarations:  7 

Seneraliia  initialization  in  typa  daelaratlons:  30 
Not  recursive/ reentrant  declaration:  1 
Variable  r.uxber  al  paraaeters :  19 
Guaranteed  6y-valua  calls:  6* 

Chants:  Define  par aneter  passing:  16 

Reference  passing  preferred:  1« 

Functionality  should  not  6a  coapller- verified:  06 
Lika:  Initialization  in  daelaratlons:  19 

Cafaull  paraaatars:  7,  19,  35 
Recursion:  10,  H,  <-2 
Functions  and  VRP's:  11,  12 

Par  Meter  acoes:  66 
Reduna:  Sac larat tons  in  blocks:  7 
Safault  paraaatars:  15 
Initial  values  In  dsclsrstisns:  15 
Cptlonallty  of  block  dsclsrstisns:  1 
Recursion  support:  13 
Tasks  and  Procedures  should  be  aerged:  5 
VRP's:  16,  19 


:mot«r  7 

Change:  Alloa  rapresaotstlons  la  prlvsts  part:  16 
Like:  lafsrsation  hlalng/csts  abstrsctlon  In  (tnarsl:  10,  14,  10, 

Ptckagss:  *,  o,  10,  "6,  19,  »G,  ‘•6,  50,  52,  56,  56,  oi,  oo, 
Prlvsts  types,  parts:  1,  6 

Sapartts  specifications:  i.  1  13,  '9,  ;6,  47,  50,  56,  69 

Racund:  Nested  packages:  '5 
Seeping  hierarchy:  '■} 

Separata  specifications:  'a 


N 


\ 


! 


CBisttr  a 

Change:  Clarification  of  M parte*  compilation  ana  visibility:  1 
Loop  indax  snculd  b*  valid  bey  one  ena  of  loop:  2' 
Rastrieteo  la  poor  kayvorn:  15 
Visibility  ruias  disliked:  1j,  16,  *9 
Lika:  Logical  scop*  rules:  16,  16 

Restricted  visibility:  ■>,  22.  25,  5$,  67 
Private  types:  o7 
fiedund:  use  clause:  15 


CtilBtlf  i 

Add:  Eackground  tasks:  lj 

Initiate  parameters :  11 
Mutual  exclusion  to  cats  access:  22,  25 
Timed-cut  entry  calls:  jO ,  66,  o7 
Suspend  and  resume  of  tasks:  62 
Easier  cyclic  nhadullnc :  66 
Chance:  Lisallow  oats  tnareo  Between  tasks:  20,  21 

forbid  abort  in*  or  chan(ln«  priority  of  parent  tasks:  6,  65 

Interrupt  semantics:  Ip,  26,  &2 

More  control  over  scnedulin*:  1j,  26,  62 

Preemptive  priorities:  27 

Rendezvous  too  restrictive:  15 

Static  priority:  1 

Like:  laskln*:  A,  1C.  20.  21,  27,  26,  si.  71,  75.  77.  65.  65,  66,  bo 

Task  families:  66 
Rendezvous  arguments:  25,  56 
Record :  laskln*  too  complex:  15 

Signals  and  semaphores :  50 


StltBUfnlfl 

Change:  Allowing  oaf erred  constants  to  be  set  in  a  separate  compilation  unit 
Have  different  visibility  rules  for  separate  compilation:  50 
Separate  wits  should  have  full  upward  visibility:  67 
Like :  Program  structure :  16 

Separate  compilation:  10,  15,  26,  5k,  66,  72,  75,  o7 


c&iaiRr  n 

Like:  Exception  handling:  7,  16,  20,  25,  55,  56,  56,  66 

Change:  Exceptions  in  declarative  parts  should  propagate  up:  66 


wtilBlRf  U 


5 


Rad:  lype  restrictions  for  generic  ptruiciri:  a,  o5 

Component  mu  u  generic  pariaeteri :  25 
Change:  Generic! :  20 

Like:  Generics:  2,  16,  56,  56,  66,  66,  67,  66 

Recunc:  Generics:  5,  65 


Chanter  It 


idd:'  Overlays:  1,  26 

Representation  o l  integers  aa  bit  deles:  16 
Record*  with  overlapping  fields:  26 

Rep«tsentatloa  specification  of  fixed  point  binary  point:  16,  15 
Ratter  Fortran  interface:  67 
Change:  laprove  alignaant  specifications :  15 

Machine  coca  inserts  clunsy:  15,  kl,  67 
Incorporate  representations  into  type  oefinitlona:  27 
Like:  Record  representation:  15.  56,  6k 

Representation  specifications:  15,  27,  56,  06 
Machine-cooe  insertions:  27 
Unsafe  conversion:  66 


Chanter  16 

Add:  liaeout  on  1/0:  11 

Fortran- like  Formats:  G 
Mixed- node  files:  o2 
k  high-level  real-tine  1/0  aachanlsa:  62 
Change:  EOF  not  exception:  Ik,  62 
1/C  incomplete:  15 

Operating  systea  aaauaeo  too  big:  15 
Extend  7ext_I0:  G 
Lika:  1/0  as  package:  1,  7 

Redund:  Senc_control ,  heceive_control  (in  Lov_levalJLO):  1 


Ctaaiir,  i 


Change:  Keyvoroa  are  ovdrloaoed:  67 

Like:  Matching  keyvoroa  (eg  LI  —  endlf):  67 


-est  and  BUliafcififl  »«Por*  Data 
2*  March  1980 


Format 

Nuaber.  Institution  [country!:  author 

General  description  —  ( B )  means  program  was  redesigned 
Original  language! s) . 

Host  eomputer(s)  ->  "argot  eomputer(s)  f if  given). 
Nuaber  of  Ada  statements  and  identlfers  used  ( if  given) 

"•*  indicates  that  the  information  was  not  given  in  the  TEX 


1.  University  of  Tork  [England!:  I.  C.  Pyle 

Non-text  I/O  of  coded  tine  signals  in  real  tlae 
Hodula 

DEC  PDP-11  ->  DEC  PDP-11 
28  statements:  32  identifiers 

2.  Hughes  Aircraft:  "ony  Sepan 

Peal  tlae,  multiprogramming  systea 
Hi ft  ran  (Structured  Tort ran) 

DEC  POP- 11/10  ->  DEC  POP- 11/70 
276  stateaents;  i5i  Identifiers 

3.  -  [Japan!:  - 

PL/ I  syntax  checker 
CPL-B  (PL/I  tubset) 

-  ->  Fujitsu  M,  Hitaohi  M,  NEC  ACOS,  Mitsubishi  Cosao 
U7g  statements:  1«0  identifiers 

U,  Aerospace  Corp,:  Charles  A.  Cruamer 


IBM  360/75  ->  IBM  ASP  202 
200  statements:  70  Identifiers 

5.  -:  Lt.  Robert  C.  Seigrlst 

*  Student  text  processing  exercise 
Cobol 

Burroughs  6700  ->  Burroughs  6700 
31  statements:  10  identifiers 


-  2  - 

6.  Institute  for  Defense  Analyses:  V.  Schneider 

PAS  Reel- tine  executive 
SPL  (Jovial) 

CSC  7600  ->  *c A  SCP-23* 

10*  statcseots 

7.  International  Computers  Ltd.  [England]:  T.  A.  Montgoaery,  1.  Marshall 

Fora at ted  listing  of  coapller  output  (CRET,  Map,  etc.) 

S3  (Algol  68) 

ICL  2900  ->  ICL  2900 

611  stateaents:  230  Identifiers 

8.  Naval  Surface  Weapons  Center:  Marc  Hubbard 

Real  tlae  fire  control 
Asseabler 

ibm  370,  urr-20  ->  unc-20 
191  stateaents:  39  identifiers 

9.  Air  Force  Araaaent  Division:  Lt.  Col.  Wllliaa  A.  Whitaker 

Inertial  guldance—ccaputational  kernel  !  R ) 

Fortran,  Jovial 
0  stateaents:  0  identifiers 

10.  Coaputer  Sciences  Corporation:  Dale  D.  Hurtig 

Real  time  digital  autopilot 
Asseabler,  Fortran  Subset 
HP  •>  Special  purpose  aicro 
i*8  stateaents:  t 1 8  identifiers 

11.  Chalaers  University  of  Technology  [Sweden):  Sven  'afvelln 

Data  buffering  and  spot  processing  in  a  radar  systea  < R ) 

Pascal 


12.  RA DC/ISIS:  Capt.  Clair  Rolla 

Data  oanlpulatlon,  word  packing  and  unpacking 
Jovial 

Honeywell  6080  ->  Honeywell  6080 
550  stateaents 

13.  General  Dynaalcs:  - 

Real-tiae,  aultlprograaalng,  data  baaes,  network  support 
C 

DEC  PDP  11/3*  ->  DEC  POP  11/3* 


1*.  IBM  Corporation:  - 

Character  handling,  video  display  formatting,  control  block  'oraattlag 

Asseabler 

IBM  360  ->  IBM  360 

689  stateaents:  336  identifiers 


-\~ 


-  3  - 

'5.  IBH  Corporation:  - 

Telops:  Satellite  data  capture,  storage,  and  retrieval 

Assembler 

IBM  370  ->  IBM  3T0 


16.  IBM  Corporation:  *  |  1 

VEPC :  Signal  processing  simulation:  bits,  arrays,  nimbers 
Fortran 

IBM  370  ->  IBM  370 

17.  IBM  Corporation:  - 

Terminal  communications  package:  character  string  translation 
Fortran 

Interdata  9/32  ->  Interdata  9/32 
256  statements:  35  Identifiers 

18.  IBM  Corporation:  -(H) 

Fixed  point,  I/O,  representation 
CMS-2T 

AM/inriC-7  ->  »M/UIi-7 

339  statements;  99  identifiers 

19.  IBM  Corporation:  - 

Signal  processing:  real-time,  low-level  I/O 
SPL  (Assembler) 

COC  6600  ->  AN/UIS-1 

625  statements:  210  Identifiers 

20.  IBM  Corporation:  - 

Bit  aanipulatlon ,  message  translation,  real  time  communications  (fii 

Fortran,  Assembler 

IBM  370  ->  IBM  UP1/ML-1 


21.  IEM  Corporation:  - 

Mathematical  computation,  real  tine  processing  (R) 
Assembler,  Fortran 
IBM  370  ->  IBM  4P1/ASP 


22.  IBM  Corporation:  - 

Real-time  Processing 
Assembler 

IBM  370  ->  Zllog  280 


23.  IBM  Corporation:  - 

Character  Handling,  String  handling  (R) 

Assembler 

IBM  370  ->  IBM  370 


"A  r- 


20.  IBM  Corporation:  _ 

String  4  character  handling,  rioor  mathematical  computations 
PL/1 

IBM  ro  ->  IBM  370 

IS!  statements:  31  identifiers 

25.  IBM  Corporation:  - 

Solo:  Single-user  operating  system 
Pascal 

DEC  POP- 11/05  ->  DEC  POP- >1/05 
1268  statements:  052  identifiers 

26.  Grumman  Aerospace  Corporation:  Charles  Mooney 

Real  time  trainer:  equations  of  motion  (R) 

Fortran 

Interdata  8/32  ->  Interdata  8/32 
155  statements:  197  identifiers 

2T.  E-Systems  Inc.:  T.  W.  Jones 

Hardware  driver:  I/O,  bits,  real-time 

Assembler 

UYK-20  ->  UTK-20 

83  statements:  31  identifiers 

28.  System  Development  Corporation:  Erwin  Book 

Simulation  of  "El"  table  (R) 

Moduia,  ALGOL,  Sue,  Jovial 

Burroughs  7700,  IBM  370,  ANFSQ-32  ->  Burroughs  7700,  IBM  370,  ANFSQ-32 
350  statements:  l»3  identifiers 

29.  Sperry  Unlvae,  Defense  Systems  Division:  - 

Display  fault  table:  characters,  data-base,  reentrancy  (R) 

DS PL  (Pascal) 

Untvac  1100,  Unlvae  1600,  AN/UYK-20 ,  Unlvae  1600,  AN/UYK-20  ->  N 


30.  SPL  International  [England):  Brian  Dobbing 

Process  control:  real-time,  operator  1/0 
RTL/2 

DEC  POP-1 1/3«  ->  DEC  PDP-11/0# 

588  statements:  580  identifiers 

31.  Hollendse  Signaal  Apperatcn  B.V.  [Netherlands]:  Phillip  van  Llere 

Instrument  servo  control  (R) 

•  RTL/2,  Assembler 

Hollanose  Signaal  »R-MU  ->  Hollendse  Signaal  SMR-KU 


32.  Raytheon  Company:  T.  Nedzynski 

Interactive  coordinate  transformations:  matrix  operations  (R) 
Fortran 

Univao  1108  ->  Uulvac  '108 
69'  statements:  96  Identifiers 


33*  Mar*. I.i  Marietta  Aerospace:  U .  3.  Carson 

Event-driven  automatic  reconfiguration  01) 

Fortran,  Assembler 

DEC  PDP-11/T0  ->  DEC  PDP-11/70 


3*.  UK  Coral  66  Teaa  [England] :  D.  V.  Shorter  l  K.  Resander 
Process  control:  graphics  (R) 

Coral  66 

DEC  PDP-11/»5  ->  DEC  PDP-11/45 


36.  Bureau  of  the  Census:  - 

Generalized  aass  storage  sort:  heavy  1/0  (R) 
Aaseabler 


36.  Lund  Institute  of  Technology  [Sweden]:  - 

Process  control  with  operator  (oodel  program) 
Pascal,  Concurrent  Pascal 
DEC  LGT-1 1  ->  DEC  LSI-1 1 


37.  McDonnell  Douglas  Astronautics:  • 

Real- tine  processing,  Array  processing,  Fixed  point  arlthaetic 
Aaseabler 

CDC  Cyber  ->  RCA  SCP  ?3» 

200  stateaents:  350  Identifiers 

38.  Air  Force  Coaaunlcatlons  Coaputer  Prograaalng  Center:  Jaaes  E.  inert 

Real-tiae  coaaunlcatlons 


39.  The  Mitre  Corporation:  Maureen  H.  Cheheyl 

ACCAT  Guard 
Gypsy 

DEC  TOPS-20  ->  - 
3T  stateaents:  16  identifiers 

40.  CMACS,  National  Physical  Laboratory  [England]:  Maurice  Cox,  Sven  Haoaarllng 

Nuaerleal  software  library  (R) 

Algol  60,  Fortran 
portable  ->  portable 


41.  TRW  Corp.:  H.  Hart,  J.  Thoapaon 

Benchaarlc  flight  algorlthas:  aatheaatlcal 

Jovial  J73/I3 

DEC  PDF- 10  ->  DEC  POP- 10 

1000  stateaents;  394  Identifiers 


. *Mmw*0>*l**>' 


42.  General  DyoaBi.es:  - 

Aviooics:  nu»b«rs,  bits  (B) 

Jovial  J3b 

IBM  3033  ->  M362-F2 


43.  General  Dynamics:  - 
Display  generation 
Assembler 

Intel  8080  ->  Intel  8080 


44.  General  Dynamics:  - 

Real  time  processing  <R) 

PL/M 

MDS-80  ->  Intel  8080.  microprocessor 
10  statements:  8  identifiers 

45.  General  Dynamics:  - 

-  (R) 

Jovial  J 38 

IBM  3^0  ->  Del co  M362F 


a*.  Grumman  Aerospace,  Software  Systems  Dept.:  J.A.  Garry 
Trajectory  computation 
Fortran 

IBM  360  ->  Honeywell  6060 
57  statements:  52  Identifiers 

47.  Grumman  Aerospace,  Software  Systems  Dept.:  J.  Kmeicllt 

Special-purpose  data  base  manager 
Assembler 

Interdata  8/32  ->  Interdata  8/32 
291  statements:  29  identifiers 

48.  Grumman  Aerospace,  Software  Systems  Dept.:  R.  Kellner 

Real-time  flight  control 

Assembler 

-  ->  Honeywell  5301 
27  statements;  39  Identifiers 

49.  GTE  Sylvanla  Inc.:  Charlene  Hayden 

Real  tine  processing 
CMS-2 

IBM  370  ->  AH/UIlC-20 
62  Identifiers 


50.  The  Foxboro  Co.:  M.  8.  Gordon 

Model  controller  operating  system  (R) 
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5'.  The  Foxboro  Co.:  N.  E.  Robinson 
Industrial  controller  ( R ) 

Assembler 


52.  Ur  Force  AFAL/AAT:  Alfred  J.  Scarpelll 

Avionics  local  executive 

Jovial  JT3/1 

DEC  PDF- 10  ->  AN/ATK-15 

533  statements:  285  Identifiers 

53.  Texas  Instruments:  - 

Benchmarks:  CPS,  Image  processing 
Assembler,  Pascal  (HicroTIP) 

-  ->  TX  9900 
2000  statements 

5*.  Burroughs  Corp.:  Jane  Powanda 

Real-time  operating  system  (R) 

Assembler  (CAL) 

Burroughs  77«  ->  - 
200  statements 

55.  Army  'JSACEEIA:  Leon  !.  Dixon 

Message  annotator 
Assembler 

AS/5  (IHH  370)  ->  AS/5 

300  statements:  200  Identifiers 

56.  AAI  Corporation:  R.A.  Duff,  R.L.  MnGarvey 

Disk  1/0  (R) 

Pascal 

Perkin  Elmer  7/32  ->  Perkin  near  T/32 
300  statements:  305  Identifiers 

57.  Technology  Service  Corp.:  D.  Hoi 1 ingmorth ,  J.  Lloyd 

Array  processor  Interface  (R) 

•  ->  Goodyear  Staran 
’66  statements 

58.  Rockwell  International :  John  L.  Whited 

Communications  operating  system 
Assembler 

Data  General  Eclipse  ->  R0LH  1602 


59.  Georgia  Institute  of  Technology:  Fred  Cox 
Fire  control  <R) 

Asseabler,  Fortran  (Flees) 

Data  General  Eclipse  S/130  ->  RdCM  1602A 


60.  (Obsolete) 


61.  Georgia  Institute  of  Technology:  Lawrence  J.  Gailaher 

Tracking  radar 
Fortran  (Flees) 

Data  General  Nova  3  ->  Data  General  Nova  3 
2035  statements:  2*0  identifiers 

62.  Honeywell:  P.D.  Stachour ,  F.G.  Christiansen 

Character  processing 
95  statements 

63.  Honeywell:  P.D.  Stachour,  F.G.  Christiansen 

User  command  (R) 

PL/I 

Honeywell  level  68  ->  Honeywell  level  68 
38  statements:  23  identifiers 

6*.  Systems  Consultants  Inc.:  - 
Coeaand  processor 
CMS-2Y 

an/uyi-t  ->  AR/urr-t 


65.  Systems  Consultants  Inc.:  . 
Document  indexer 
Fortran 

HP-3000  ->  HP-3000 


66.  Honeywell  Avionics:  J.  H.  Kamrad 

On-board  real-time  control  system  (R) 

Assembler 

Intel  8085  ->  Intel  8085 
166  statements 

67.  Honeywell  Avionics:  C.  taodow 

Flight  executive  (R) 

Assembler 


68.  Honeywell  Avionics:  J.  H.  Holeehbaeh 

Real-time  radar  detection 
Assembler 

Intel  8085  ->  Intel  8085 
<90  statements:  89  Identifiers 

69.  IA8G  [Germany):  Peter  Burfclnshaw 

Graph  theory:  Hamiltonian  path  finding 
Pascal 

CDC  Cyber  ->  CDC  Cyber 
93  statements:  21  Identifiers 


70.  HQ  SAC/ADSV :  Lt .  Thomas  J.  Croak 
mathematical.  calculations  (R) 

Assembler 

Uoivae  1100/*2  ->  Univae  1100/42 
16  stateaents:  6  Identifiers 


71.  - 

Conditional  test  lad ,  bit  aanipulatlon  (R> 
CMS-2Y 

lll/m.7  ->  AN/OYE-7 

159  statements:  37  Identifiers 

72.  Perkin-Elaer  Oats  Systeas  Group:  - 

Interactive  transaction  processing  systea  (R) 
Asseabl er 

Perkin-Elaer  7/32  •>  Perkin-Elaer  7/32 


73.  Hughes  Aircraft  Coapany:  J.  Hhita  tr 
Real-tlae  fire  control  systea 
CMS-2T 

AH/UTIt-7  ->  AM/tIYE-7 


74.  British  Airways  (England]:  - 

Record  1/0  package 

Neliac,  Assembler 

DEC  POP- 10  ->  DEC  POP- 10 

29  statements:  66  identifiers 

75.  HO  SAC/ ADOS:  U.  Steven  C.  Bush 

Database  aanager  '■  R ' 

Fortran,  Aasaabler 

IBM  360/8?  ->  IBM  360/89 

40  statements:  9  identifiers 

76.  Air  Force  ASD/ADSD:  Lt.  Steven  K.  Rogers 

Real-tlae  0(0  Analyzer;  Cross-assembler  (R) 
Fortran,  Aasaabler 
-  ->  Intel  8089 


77.  Pacific  Missile  *est  Center: 

Diverse  flight  software 
Metaplan 

Xerox  960  ->  CDC  9400B 

24  stateaents 

78.  Naval  Avionics  Center:  - 

Navigation  Computation  ( R ) 
Asseabler 

Honeywell  639  ->  AYlt-14 
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79.  Naval  Avionics  Center:  - 

Dual  processor  Interface  test 

Assembler 

Honeywell  635  ->  ATI-1* 


80.  Naval  Electronic  Systems  Co— and :  - 
Communications  aodule  (R) 
Assembler 
UYK-7  ->  UTK-20 


81.  Dept,  of  the  Navy:  - 

Mathematical  computation,  comparison  and  Interpolation  (R) 
Fortran  IV 

SEL  32/55  ->  SEL  32/55 

383  statements:  '*9  Identifiers 

82.  Dept,  of  the  Navy:  Robert  Zlle 

Real  time  mathematical  computation  (R) 

Fortran 

AN/UTK-7  ->  AN/UTI-7 

925  statements:  150  Identifiers 

83.  Dept,  of  the  Navy:  - 

Mathematical  computation  (R) 

Fortran,  CM3-2,  Assembler 
-  ->  IBM  *P1 

200  statements:  90  Identifiers 

8*.  Dept,  of  the  Navy:  - 

Mathematical  computations  (R) 

F-  in.  3PL/I 

(  600  ->  CDC  6600,  ASP 

5 '•  j  statements;  15*  Identifiers 

85.  Naval  Surface  Weapons  Center:  Marc  Hubbard 

Real  time  processing,  fixed  point  arithmetic 

Assembler 

IBM  3’0  ->  UKI-20 

191  statements:  39  identifiers 

86.  -:  - 

Generic  menu  package  (R) 


87.  Sanders  Associates:  Robert  E.  Rice 
FFT,  search,  sort  < R ) 

Fortran,  Pascal,  Mortran  (Fortran),  Ratfor 
DEC  Vax  11/780  ->  - 
76  statements:  26  Identifiers 
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86.  NeDonneil  Douglas:  J.J.  Cobble 

Autopilot,  data  base,  aessage  handler 
isseabler 


89.  Naval  Be search  Laboratory:  H.  Cronin,  J.  Gannon,  D.  Weiss 
Software  engineering  tests  (R) 


3LJI 

4.1  finbptrlng  tba  particular  pcagra  Z  coded,  there  would  be  no 
significant  difference  batw— l  Hcdula  and  Ada,  but  tot  tuctbac 
derail  fits  I  think  Ada  would  ba  faster  bacauaa  asperate  nooulaa 
could  ba  taad  without  re-editing. 

4.1  It  U  aoca  voluminous  and  aaaaadiat  repetitive,  but  this  is  aoca 
often  a  help  than  a  hindrance.  Suppl— ttad  by  a  lyabol  table  ana 
ezoas  rthtnet  list  it  would  ba  vary  auch  aoca  caaaaola. 


3  42 

2.4  . .  .Ada  vac  don  is  a nee  portable. 

4.1  Ada  dwolapaant  abould  ba  fastest  duo  to  ability  of  coapiler  to 
flap  illegal  or  awcthodoai  ending.  It  is  assusad  9000  nabuggmg 
tools  will  support  tba  Ada  dsveiqpaot  tyita. 

4.4  Mary  little  would  ba  gained  by  using  Ada  escape  tor  portability. 

4.5  All  depends  on  adequate: 

-  training 

-  documentation 

-  availability  of  iabouae  expertise 

-  Ada  oospilec  (officiant  coda  produced,  super  error  -detection) 

-  support  software  (library  interfaces,  Ttffl  1C.  StAACAKi,  etc.; 

-  a  friendly  development  envixoraeent  system  * 

-  developaant  of  a  set  of  Ada  programing  practices 


3  43 


3.1  Zbe  concept  of  TKtiga  wan  every  to  under  stand  out  difficult  to 
uae.  Reference  naoual  didn't  mention  vnace  to  write  to  oeqin  with. 

4.2  In  CSL-*  (ease  as  Wl) ,  ispUcit  type  conversion  is  tne  nose 
error  prone  feature. 

4.4  Aa  for  language  feature,  C3H  is  poeacful  enough. 


1.2  Paaciraa  auch  as  aocaas  types,  private  types,  ano  ewacloaoing  aia 
not  sees  tn  land  thanaalves  to  tba  project  chosen.  Apparently  u 
the  designer  does  not  bsea  Ada  in  kind,  the  daaign  does  not  lens 
itself  to  many  of  tbo  new  ideas. 

3.3  A  conspicuously  absent  almane  is  tbs  hierarchical  el  apery  t. 

3.4  Ada  aamMd  to  be  *de  to  aecesbodata  any  situation  that  arose  ir.  this 
application. 

4.1  It  would  tabe  longer  to  develop  a  debugged  pragma  in  Aoa  than  e.g.  m 
HP'  s  W>  (Program  bevel opnant  and  Maintenance  system.;  me  author 
of  PCM  decided  to  keep  tba  language  staple  and  wpose  part  or  tne 
methodology  through  the  environment  e.g.  id  linear  code  sut.  aueestatic 
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indenting.  No  language  can  guarantee  quality  programing,  mere  must 
be  training  aeesions  and  a  attic c  Methodology  agreed  upon  by  the 

4.2  I  feel  that  strong  typing  is  feeportant  and  wen  facilitates 
coding. 

4.3  As  1  Mentioned  move,  I  think  that  Ada  could  be  considerably 
aoce  readable.  The  syntax  is  Many  times  obscure. 

4.5  The  aain  problmi  that  would  arise  is  that  the  paraonnel  would 
have  to  be  sold  an  the  advantages  of  Ada  over  e.g.  KSXfmk. 

4.9  FM3NZ,  nsnos,  and  TASK  are  particularly  brill^ast. 
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2.7  Yes.  Ihe  Ada  constructs  ptved  such  sore  adaptable  than  Cabal. 

3.5  Since  the  Ada  design  wee  so  Much  More  compact  and  simple  than 
the  Cobol  prograa  1  decided  to  implement,  •  snre  sequential  aethoa. 

3.6  The  pragma  sssms  very  clear  and  efficient. 
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2. 2  The  aein  amecutacle  portions  of  the  new  design  ere  such  easier 

to  read  than  the  original  herauae  they  are  auch  shorter,  with  portions 
of  the  original  coda  relegated  to  subroutines. 

3.6  Reeading  in  Ada  reeu)<-tJ  in  a  snail  iapconsesnt  in  stnrage 
efficiency  for  this  example. 

4.3  ^organization  with  conditional  atatmeants  improved  the 
certkalliey. 

4.4  (king  Ada  probably  would  have  the  same  effect  as  any  other 
modem  language,  like  Pascal  or  tt/1. 


0  I  believe  that  our  wparienee  is  particularly  important  because 
we  are  compering  Ada  with  a  powerful,  modern  language  bases  an 
Algol-66.  lave  Ada  types  mic,i  ere  such  aigierior  to  our  am, 
but  we  find  that  Ada's  rigid  etacamant  ttructurs  prevents  us  tram 
writing  natural  solutions  to  oir  problems. 

0  With  this  one  asceptlon  we  are  on  the  mole  pi  used  with  Aoa. 

3. 3. 2. 2  Little  acope  wee  found  for  derived  types  or  subtypes... 

3. 3. 2. 3  Extensive  redesign  of  soma  existing  interfaces  wee  requires. 

to  circumvent  the  lack  of  row  of  procedures,  mich,  though  acceptable 
in  the  case  of  INS,  would  have  presented  an  unacceptable  overhead  in 
the  case  of  a  program  auch  as  the  S3  compiler 
We  fear  that  Ut6An_PKXBAmilG  will  t»  a  pr  Jtant  feature  in 
prograae  which  must*  inter  face  with  non-ADA  -e,  or  mien  must  be 
very  compact  or  efficient. 

3. 3. 2.4  Generic  packages  are  a  powerful  facility  and  we  usee  them 


to  provide  procadixs  paramters  to  a  tree  walking  package.  however , 
we  feel  that  a  run  time  par matar  nation  is  necessary  (Llx  bj/D . 

3. 3. 3.1  ADA  compare*  wall  with  S3  in  terms  or  readability  of  source 
cod*.  It  acotas  heavily  by  the  introduction  of  enumtration  types, 
which  are  a  aajac  aid  in  self  docuuantation.  Similarly,  the 
exception  handling  facilities  encourage  readability  by  separating 
error  handling  ft an  the  urn  path.  Tbe  use  of  default  parameters 
is  a  further  asset.... 

Seme  of  the  syntactic  features  of  ADA  hinder  readability,  bowevar. 
These  are,  notably  tha  lack  of  cenJitional  expressions  an a  toe 
absence  of  eempaund  statement*....  The  veeboeity  of  ADA  further 
hinders  readability,  in  particular  the  ccaplaxity  of  array  slicing. 

The  syntax  of  a  block. .  .discourages  the  declaration  of  aata  near 
to  the  point  Wwre  it  is  used.  The  syntax  of  aggregates...  is 
preferred  to  the  S3  equivalent. 

3. 3. 3. 2  Ada,  on  the  tdtole,  is  a  sore  verbose  language  than  S3, 
although  in  sobs  areas  it  uaprovet  on  it.  ...acme  features  of  Aoa 
■ay  actively  encourage  programing  errors  and  so  reduce  programwr 
productivity: 

(1) .  The  significance  of  break  characters  in  identifiers; 

(2) .  Need  to  introduce  hlocxs  to  introduce  im  local  aata  items; 

(3) .  conditional  aqreesiona  not  being  permitted; 

(4) .  reapaeifying  type  declarations  in  order  a  aod  e  representin' 

specification. 

3.3. 3.3  Ada  code  aay  well  prove  a  be  more  aaintninable  than 
equivalent  S3  Code  aa  a  result  of  it  being  acre  self  Commenting. 

3. 3. 3. 4  Ada  permits  more  elaborate  run  tie  checking  than  aoee 
S3....  Ada  training  ooursee  mnuld  eagbaaia*  correct  use  of  types. 

3. 3.3.4  ...our  experience  with  S3  is  that  [reference  variables] 
are  a  valuable  tool  in  the  bands  of  the  expariancet  programar. 

3. 3.3.3  The  separata  compilation  system  is  note  versatile  tnan 
that  of  S3.... 

3. 3. 3. 6  Ada  looks  to  be  sxcellent  in  engendering  portable  programs. 

3.3.3. 7  The  escape ion  handling  facility  of  Ada  provide*  a 
convenient,  high  level  way  of  handling  errors  detected  within  nested 
procedure  calls. 

3.3.3.10  Ada's  prmlsion  of  this  facility  [Input-Output]  is  a 
considerable  advance  on  S3. 

3.3.3.11  Both  Ada  wd  S3  are  suitable  language*  for  programing  in 
the  large,  with  the  nodular  aspect*  of  Ada  being  further  enhanced 
by  nesting  package*  and  having  vltibl*  and  privat*  parts.  ...th* 
proposed  compilation  (ysttm  lends  itself  to  large  scale  noftware 
construction  tystms,  rather  than  one-one-off,  mail  scale  progressing. 
Ada  it  not  very  easy,  either  to  learn  ot  write,  particularly  in 

that  It  Introduces  several  features  fersign  to  Algol -ee-lire 
languages. ...  An  S3  styl#  of  progrmming  bassrt  on  nesting  ot 
constructs  ha*  evolved,  and  mi  Ada  style  doss  not  grow  easily  out 
of  this.  The  mgftasis  on  statements  rather  than  expressions 
seaas  rstrograde,  and  tha  very  strong  typing  will  provs  iresome 
to  systasw  progrmsHts.  Generic*  in  particular  are  difficult 


to  grasp, 


kith 


3.1  Ns  war*  rat >4iat  confused  fine*  string*  ar*  meaay  caparao 
reference*  to  strays  es  u**d  in  S3. 

4.1  Ads  cad*  will  probably  take  long«r  to  writ*  than  equivalent  S3 
cod*  btuuM  of  th*  v*rbo*ity  of  th*  language.  N*  expect  that  the 
tu>*  taken  to  debug  a  pxogra  will  b*  l**s  aa  a  caault  of  tba 
atensiv*  nn  Ujm  chocking,  and  bacaua*  [aanyl  potential  rut  time 
bug*  ar*  foind  during  caspilstion.... 

4.4  Ada  t*  likely  to  appear  in  a  better  light  Wat  a  software  systaat 
is  designed  with  th*  knowledge  that  Ada  will  b*  used  as  tbs 
tmpl  — ntatlnn  language. 

4.10  Ada  has  derived  many  useful  featur**  term  its  PASCAL 
background ,  particularly  it*  excellent  typing.  It  Beau  e  pity  that 
■any  of  the  useful  features  of  Algol  bS,  particularly  its  expression 
structure  and  ua*  of  raferenc*  types,  have  not  been  siaularly 
incorporated  in  Ada. 
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2.3  Ue*  of  packages  helped  trsaandoualy  to  define  the  interfaces 
and  Data  Base  Types,  bujarated  types  were  also  beneficial.  Type 
definitions  war*  sswrstic  and  readable. 

3.1  ...1  kept  emitting  OCX 1  for  XT  statasents  of  fw  if  condition 
then  Mtaatt  (single)  probably  a  c  i  —on  aistaka. 

3.4  The  constructs  allowed  for  proper  expression  of  ay  program. 

No  certain  constructs  ar*  disturbing  to  ae. 

4.1  Development  time  would  usually  be  about  the  sue,  if  not 
shortar ,  than  aost  languages.  Compiler  will  catch  easy  ■iscakas. 
Learning  Ada  may  be  longer  than  usual. 

4.3  Source  cod*  in  Ada  is  as  reaUbl*  u  other  language*. 

4. 4  production  would  increase  since  aost  programing  is  dune  in 
■semdily  language.  Progra  maintenance  would  be  more  easily 
performed  and  transition  to  another  per  son/ agency  would  be  ■mother. 
Because  of  cempilex,  many  mistakes  will  be  caught  at  coepil*  use 
and  not  during  executions. 

4.9  (Tasking)  is  easy  to  mderstand  and  ua*.  Private  types  ana 
package  structure*  ar*  also  well  designee  and  should  be  unchanged. 


0  Th*  working  part  of  th*  progra  was  enormously  shorter ,  ana 
for  ths  first  ti*s  it  ni  readable  in  s  ton  fail  1st  to  one 
versed  In  ths  science. 


3.4  Qi  Were  there  any  inter  actions. .. 


that  caused  you  difficulties? 


Ai  No 


4.1  NS 

4.2  ...[typs  checking]  will  facilitate  debugging  ana  increase  the 
reliability  of  etas  progrm. 

4.3  fosl  9m  black  and  statement  structure  facilitata  readability. 

4.6  Expect  to  encounter  tha  same  problems  ana  always  encounters 
with  now  tools. 

4.7  Ns  cadvndant  features  mich  mould  ba  dalacad  waca  datactao... 

4.8  ...not  wa  that  changes  ace  required. 
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3.1  I  had  no  difficulties  to  nidac stand  tha  different  faatucas  in 
tha  Imgiaga. 

4.1  It  will  taka  mortar  tuna  to  progem  in  Ma  than  in  other 
languages. 

4.3  9m  coda  written  in  Ma  is  gansrally  note  readable  than  peogems 
written  in  amt  other  lasguagea. 


TO.  412 

4.4  9m  currant  project  uses  a  aixtira  of  several  languages.  Using 
only  Ada  aaans  that  a  maintenance  pragraamr  only  baa  to  laarn  am 

language. 

4.6  I  would  strongly  rsummiJ  it  bacaum  of  tha  srructuras 
prmji  —inq  techniques  that  Ada  mcowages. 


Tnt  «13 

0  Our  mjoc  conclusions  are  that  Ada  is  suitable  for  both 

ermputer  software  rnd  sipport  software,  be  are  concerned, 
however ,  that  tha  high  cmpleeity  of  tha  language  ana  its 
restrictive  type  checking  nay  result  in  inconsistent  and  inefficient 
use  of  the  language  and  higher  than  anticipated  life  cycle  costs. 

2.3.1. 2  For  nuatrical  processing  Ada  deserves  praise  as  in  its 
ability  to  define  precision  by  specifying  the  nuabsr  of  digits,  the 
range,  or  the  delta.  In  empariaon  with  other  languages.  Am  is 
rated  satisfactory  to  superior... 

For  raaltim  asacutive  support  Ada  Is  inadequate.  It  auet  be  nooiliao 
to  recognise  that  interrupts  mat  ba  processed  prewptively. 

2.3. 2.1.1  ...Ada  would  be  quits  sufficient  in  these  areas,  (separate 
compilation  etc.)  and  offers  decided  advantages  over  the  corresponoing 
PL/M  constructs. 

2. 3. 2. 2  In  uny  respects  Ada  would  be  a  sore  suitable  language... 
than  PL/M,  even  though  PL/M  sense  to  be  specially  oriented  to  this 
kind  of  ^plication. 

2. 3. 2. 3  ...Ada  offers  excellent  facilities  in  the  area  of  program 


variable  declarations. 

2.3.3. 3  Ada  does  have  good  data  constructs  with  powerful  IT  and 
CASE  stats— >ts. 

2.3. 5.3  tbm  Ada  latguag*  nay  be  acceptable  for  tbs  develop— it 
of  [operating  syrtee)  due  to  tbe  flexibility  of  the  language. 

2.3. 6.3  Hie  visibility  rules  only  suite  the  language  note 

difficult.  Usually ,  _ an  data  only  confuses  aalntenance  progcaaaart 

without  stopping  anyone  intent  an  violating  the  systv  security. 

2.3. 7.2  ...Ada  as  it  stands  now  would  not  be  suitable...  due  to 
the  say  in  thich  it  —vices  interrupts.  If  the  requested  change 
were  suds...  then  the  determining  factor  for  Ada's  ussfulnsss. . .would 
be  Ada's  efficiency.... 

...vb  11  a  the  currant  version  of  Ada  it  not  useful  for  this  kind  ot 
application,  future  versions  could  be  changed  to  be  suitable. 

2.4  ...Ada  ia  apparently  suitable  tor  the  generation  ot  support 
software  of  software  tools. 

2. 5. 1.1  the  currant  Ada  pointers  are  iaiuaaeble  tor  static  oat a 
structures. 

2.5.1.2  One  of  tbe  features  lacking  in  Ada  ia  tha  ^equate  control 
of  dpuaic  storage  allocation. 

0  In  general,  Ada  ia  suitable  tot  both  eabaddad  i-mprar  pragrans 
and  support  software.  However,  tha  design  appears  to  favor  toe 
latter. 
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2.6  ...I  didn't  know  enough  about  Ada  man  I  started.  Baa  1  know 
then  that  1  know  now,  I  would  have  never  triad  to  fit  into  an 
eclating  systaa,  rather,  I  would  have  redesigned  the  systaa  trim 
scratch. 

2.7  The  problaas  were  all  with  pointer*  and  access  types. 

3.2  none  in  particular 

4.1  Canparing  Ada  to  IW1  and  to  Assmhlar  will  probably  produce 
an  "Snout  equal’  coaparlson.  Z  chink  that  even  if  it  takes  longer 
to  tcite  an  Ada  prograi  (and  1  as  not  certain  that  it  does) ,  the 
costa  and  times  tot  aalntenance  will  be  lower.  Certainly  tbe 
readability  and  correctness  should  be  better  than  man  using 
current  larquagns. 

4. 4. A  Ada  require*  better  planning,  interface  qpeciftcatinn,  ana 
doc  mentation. 

4.4.0  0>*  use  of  a  totally  new  language  ia  an  aooeliene  vehicle  tor 
helping  to  rear we  old  habits  such  as  leaping  into  coo*  with  out 
thinking,  ua*  of  non- structured  programing ,  etc. 
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2.2  Ada  would  prarid*  better  control*  over  the  use  of  data  ana 
hence  better  uilt  level  design  in  quit*  s  few  areas  ot  tbe  systaa.... 


i 

i 


Longer  lap!  —nr u inn 


4.1  Application  logic  ahould  be  barter.... 
for  aystae  design  aid  systan  inter  foe— . 

4.2  Strong  dace  typing  gfuri  to  be  highly  overrates  aa  a 
technique  significantly  avoiding  programting  errors. 

4.3  Ada  can  be  uaad  to  create  highly  readable  code  and  does  auch 
to  diacotzage  poor  practices. 

3  3m  ada  developaent  is  in  general  auch  enhanced  by  clear  am 
precise  use  of  technical  terminology.  However  aeae  taiuaual  images 
seat  to  have  crepe  in. 
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2. 2  Though  no  redesign  *as  dene  the  code  was  better  than  before 

because  It  ms  easier  to  read. 

2.5  everything  necessary  for  array  handling  is  available  in  Ana. 
but  sane  additional  capabilities  would  be  helpful. 

2.6  By  putting  tbs  procedurss  and  data  in  panragea  chars  was  a 
better  feel  Car  the  relationship  between  variables  in  the  pcogrm. 
Saving  a  feature  like  packages  encourage!  one  to  do  this. 

3.1.1  Problaaa  arise  trying  to  figure  out  where  the  variable 
should  be  declared. 

3. 1. 4  ..in  diaeuaaiona  with  people  working  an  other  Ada  program  1 
found  access  types  very  confusing. 

3.5  More  experience  in  the  urn  of  overloading  operators  is 
necessary  before  a  decision  as  to  ttothar  or  not  to  is*  it  can  b« 

aade. 

In  general  the  coda  was  dean  and  a  good  ooapilar  would  probably 
generate  efficient  object  code  from  it. 

4.1  It  would  seen  that  prngi  — Ing/dabugging  in  Ada  would  tana  a 
little  leas  tine. 

4.2.2  ...it  would  appear  that  type  checking  is  a  vary  helpful 
aid  in  detecting  errors. 

4.3.1  The  Ada  code  is  more  readable.... 

4.3.2  3m  syntam  of  ctactants  made  the  code  lees  readable. 

4.4.1  Better  data  organisation  and  interaction  through  the  uee  of 
packages. 

4.4.2  Better  .rograa  organisation  through  the  urn  of  atructurao 
constructs. 

4.4.3  Lass  execution  tlm  errors  because  of  Ads'*  type  checking. 

4.4.4  Cleaner  amception  handling  bee  aim  of  Ada's  excaption 

eschaniae. 

4.5.4  For  a  project  that  could  be  written  all  in  Ada  and  did  not 
need  much  low  level  support...  Ada  would  ba  a  goad  choice....  for 
signal  {recessing  applications,  I  an  not  convinced  that  any  hign-levei 
language  ia  suitable. 


3.1  -  3.6  The  only  difficulty  (of  other  than  a  minor  nature* 
encountered  In  this  Ada  implaoentation  was  in  determining  the  acray 
[limit  in  racocda].... 

Although  the  Ada  data  etructire  is  definitely  superior  to  the 
FORBAD  implementation,  there  is  concern  about...  taprasw tation 

4.2  [I]  believe  that  many  error*  not  normally  detectable  until 
execution  will  be  caught  by  the  language  translator. 

4.3  The  Ada  code  resembles  the  design  language  ao  closely  that 
well -written  pragraee  ehould  require  fewer  caaaants  than  in 
non- structured  languages. 

4.6  Assuming...  [a  good 1  cempiler...  I  would  welocme  the  use 
of  Ada  cn  ay  neat...  project. 

4.9  The  textual  structure  and  data  typing  facilities  of  Aoa  are 
features  that  atould  definitely  remain  in  the  language. 
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2.2  The  redesign  ia  far  better  than  the  original.  The  program  is 
mortar  in  length...,  modular  in  structure,  wo  easier  to  reao.  in 
addition,  there  are  fewer  oontrol  flags.... 


ter  ii9 

2.6  The  Ada  code  will  be  better  structured.  Belated  objects  ace 
grouped  together  in  packages.  Readability  ia  enhances. 

3.6  Z  believe  that  dear  expression  of  the  prograe  was  passible. 

Ada  does  promote  readable  code.... 

4.1  I  think  developing  a  new  progrw  will  take  longer  in  Ada  than 
in  a  language  with  less  typing.  The  difference  would  he  in  tne 
rigorous  definition  and  specification  of  types,  initialising  pockan 
objects  by  aggregates  instead  of  hmt,  and  the  specification  of 
subrxogrw  parameter  lists.  However ,  X  believe  that  the  type 
ctw-.-king,  etc.  performed  by  an  Ada  cempiler  will  catch  many  of 
the  routine  error*  customarily  aada  in  programung. 

4.3  I  believe  w  Ada  progrw  can  be  self  documenting.... 

4.4  I  do  believe  Ada  to  be  a  very  useable  language,  unlike  some' 
other  Bats.... 
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2.2  New  design  ia  better  than  the  original  in  that  it  is  fax  mace 
robust  mid  maintainable.  The  new  design  is  not  woes*  than  tns 
original  in  any  aignifiewt  my. 

4.1  It  will  definitely  taxe  longer  to  develop  e  progrw.... 
However,  the  resulting  Ada  program*  will  b*  far  bsceac.... 

...the  extended  amount  of  time  required  to  progrw  in  Aoa  lisj  a 
c  foment  upon  eh*  haphazard  manner  in  tbich  present  oay  WUs  ace 


UMd  to  develop  DoO  KftMN.... 

4.4  An  ^plication  progra  would  stand  not*  of  •  chance  of 
being  cncrect,  maintainable,  and  modifiable. 

4.7  The  feetixes  of  Ma  are  vary  interdependent  and  vcliioM 
cannot  be  ade  without  a  great  deal  of  car a.  1  woulo  lika  to  aaa 
something  dona  *out  excessive  language  ctmplaxity...  itutj  It  it 
not  aaething  decided  by  taxing  a  vota. 
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4.1  tar  thla  particular  probla,  daval oping  a  dabuggso  progra 
would  probably  ba  aaaiat  and  faatar.... 

4.3  Aoatmptions  of  probla  aolution  ara  more  explicit.  however, 

the  coda  1*  laaa  readable  [than  that  foe  oac  special-purpose  cospilarj 

4.4  ...tha  main  advantage  Ada  provides  is  a  aat  of  wall-thougnt-out 
concepts  lika  ’task.',  “rendezvous*,  and  "antriaa*  tor  oaaling  with 
concurrency.  Ihaaa  ma  daaigning  mid  Mpl  a— iting  a  cotract  probla 
aolution  far  aasiar  than  with  ad  hoc  aultitaaking  facilxtiaa. 

4.7  9m  faaturaa  of  Ada  ara  vary  interdependent  ana  acisions 
or  chaaigaa  cannot  ba  nado  without  a  graat  daal  of  cara.  ...tbaaa 
changaa  [detail ad  list  pcacadaal  night  rrmprnmiea  language  uaaoU.it> . 
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4.1  Given  tha  laa  aid*  of  tha  Ada  learning  axva.  1  baliava  Aoa 
program  will  not  bo  aignificar.tly  nora  difficult  to  assign,  coo* 
or  debug.  Ada  ia  a  vary  concise  language,  much  aboula  allow  a 
progrmaear  with  experience  in  it  to  iaplaant  a  progra  in  it  with 
no  aoca  difficulty  tha  before. 


2.2  Tha  new  deeign  ia  definitely  more  raadabla  ana  aaintainaola. 
Bach  data  structure  ad  operation  ia  clear  a  to  its  purpose. 
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2.4  In  Ada  it  as  easier  to  ’think  Structured*  1  ini  tea  ntmber  of 
reasonable  constraint*  -  vs  IVI  this  assisted  m  in  cooing  a 
structured  progra. 

4.1  After  a  little  faUlariaation  ad  practice  Ada  coding  aia  not 
take  a  long.... 

4.4  Ada  appears  to  be  a  excellent  language  to  teach  Sasic 
programing  findaantals  in.  It  ia  readable,  fairly  easy  to  use, 
and  atraely  say  to  transfers  algorithm  eras  a  Design  language 
(e.g.,  Id,)  into. 


4.1  I  believe  that  developing  a  debugged  program  in  Ma  will  um 

(1)  Ma  la  Iwqerj 

(2)  Ma  is  net  considerably  Bora  powerful; 

I  would  aspect  Ma  Mould  ba  In  a  web  more  favorable  booting 
against  oldar  languages  sueb  as  fertrao  or  K/i. 

(3)  lbs  ability  to  us*  process**,  classss  and  sou  toes  as  true  oats 
types  in  Concurrent  Faecal  is  not  quite  eatenao  in  Ada. 

4.3  1  belie**  ny  Ada  repregrasung  of  tbs  SOLO  operating  systab  ia. 
less  readable  tban  the  original.  Ihe  Hey  reason  tor  this  is  tna 
inability  to  use  package  runes  as  farms  tars  of  oebar  packages. 
Otherwise,  it  would  base  bean  roughly  as  readable  as  cm  original. 
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4. 1  Developing  a  debugged  prograb  nay  vary  well  tans  longer  in 
Ada  tban  in  fertran.  Die  Ads  raquirmmits  ter  ssplicitly  typing 
every  variable  will  lead  to  better  program  that  are  sore  reliable 
and  probably  eaaier  to  maintain  oeor  the  total  life  cycle.  however, 
the  detailed  ^pacification  of  each  variable  type  ones  lean  to 
additional  lima  of  cod*  that  Dave  to  be  aavelopad,  oabuggra  ana 
integrated. 

4.2  tea  typ*  charting  of  var labia*  is  in  ay  opinion  a  key  f astir* 
of  Ada. ... 

4. 3  . . .Ada  did  not  saea  to  offer  any  nor*  t**n ability  tban  Fortran 
Bowevar,  if  this  was  coded  initially  in  Ada....  it  ia  conceivable 
that  highly  readable  progs'*  would  result. 

4.4  A  iruverael  (real  time)  language...  has  very  obvious  benefits 
and  this  would  apply  to  all  our  projects. 


4. 1  ... 1  feel  that  developing  programs  in  Ada  will  taka  ns  acta 
tin*  than  developing  programs  in  any  other  high  orate  language.... 

4.3  I  felt  that  Ada  is  morv  readable  than  FORM*  «r  aeaaably 
language,  but  no  more  readable  than  Fmacal  or  AtflU.. 

4.*  tea  definition  of  tasks  in  tht  language  allows  tb*  uaar  to  nor* 
easily  tee  the  tasks. 
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2.2  It  is  far  more  isidarstandabl#  tban  the  AtOOL,  H&,  or  jCArlAi. 


versions. 

3.1  My  ^plication  hi  wall  suited  to  Ada  arc  therefore  1  hao  no 
difficulty  in  eta*  uh  of  Ada.... 

3.4  1  do  foal  that  tba  pragrw  it  apraasad  clearly  are  yat  will 

rait  a  good  aapilac  to  generate  afficiant  com. 

I  ballawH  developing  a  daouggsi  pogcaa  in  Ada  will  tana  laaa 
tiae  than  in  mty  other  lanquaqa  within  ay  experience,  (lately  Jovial, 
AML  OS-2,  AMfblac,  USP,  Sua,  tASCAL,  Mdula,  a no  m  others 
that  ait  un&ailiar  to  tha  wot  Id.  ttia  ia  foe  two  principal  reasons. 
.  A  aora  tndarsundabla  prograa  can  ba  weittan 
.  A  auccaaaful  ccapilation  aaana  tasting  ia  auch  fur  that  along. 
4.3  I*  Ada  pragras  U  aota  raadabla  than  tha  4  ^  wioua  versions 
of  thia  pragma.  ...tba  Ada  agd  ■anntion  aor  a  nearly  rail  acts  ay 
daaign  concept. 

4.4  Dm  aora  people  that  work  an  a  project  tba  aora  tha  valua  of 
Ada  baciaaaa  apparent. 

4.3  If  Ada  wara  aaclueivaly  uaad  in  ay  application  acaa,  no 
prablaaa  would  raault. 

4.4  1  look  forward  with  pleasure  to  tba  uaa  of  Ada  tor  ay  naat 
aabadded  rrapirer  tyatsa.  There  will  ba  aany  tawar  prablaaa. 

4.9  1  lika  tha  ceerall  chacactar  and  oonaiatancy  of  tha  language 
and  ao  I  would  not  like  to  aao  it  clanged  in  aty  significant  way. 

4.10  Bran  bafora  Ada  ccapilars  ara  available,  tha  Unguag*  can 
ba  uMd  aa  a  daaign  tool.  It  ia  a  far  siperioc  vehicle  than  tba 
currant  crop  of  IDL's/paaidn  eodaa. 
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2.2  (Two]  radasigna...  war*  jidged  to  ba  major  iaprowanta. . .  for 
all  tha  right  taaanna  -  graatar  clarity,  aaaa  of  Bonification  ana 
taating,  top-down  daaign,  ate. 

Tha  solution*  to  tha  othar  thraa  araaa...  wars  ’ to*  satisfying. 

4.1  Lsaming  to  uaa  Ada  praparly  aeaes  to  taka  conaidwacla  uaa, 
but  it  it  a  substantial  laprormrtt  awsr  othar  laoguagaa. 

4.2  Tha  taM  balls***  that  in  ganacal  strong  typing  praaotas  gooo 
daaign  ad  facllltataa  tatting. 

4.3  %*a  asabars  had  aomadiat  conflicting  opinions  to  just  bow 

auch  aora  raadabla  Ada  coda  is....  All  agraad  that  Ana  was  at  laaat 
bat  tar ,  and  that  prograaa  we  ittan  in  Ada  would  ba  aaaiar  to  oabug 
ad  eaat. 

4.4  Ada.,  increases  tha  probability  of  writing  corract  prograaa. 

4.4  ■wsryons  but  participant  p4  dafinitaly  agraad  that  if  a  9000  to* 

coapllar  wars  available,  tbay  would  progras  than  naat  projact  in  Aoa. 

4.10  Ada  saws  to  ba  9anarally  aupaclor,  and  aJataquant  oaaigna 
Mould  ragulra  laaa  affect. 


2.  6  ft*  original  TO.  Mi*  v«ry  wall  dsaignad  and  Ad*  mealy  iUuMB 
this  assign  to  ba  mppad  Into  slight', y  battac  coda.... 

4.X.1  Algol  M  and  S3: 

Ovarall ,  X  think  that  davulcfMant  would  taka  longue  is  Ada  auo  to 
th*  rigorous  ragulrmarrts  *n  tht  daaign  ara  ooding.  Algol  a* 
program  ara  eftan  oodad  soaMMiat  * loosely*. 

4.1.2  WV2  and  Algol  60: 

Thaaa  languagaa  ara  significantly  aara  raacrictaa  and  sacure  than 
Algol  61  nS  oonaaquanUy,  I  think  that  Ada  dawulapaane  urn  will 
ba  similar  to  thaaa  languagaa. 

4.1.3  Fortran  and  Coral  64: 

tha  lnaacurity  of  thaaa  larguagas  causa*  maaaivu  aaougging  Uaa. 

Ada  dnulri  b*  such  faster. 

4.1.4  Aaaaablar  (various): 

Ada  daval  ■gaunt  tins  for  a  dabuggad  pragma  should  ba  laaaaaaurably 
battar. 

4.2  ...Ada  actively  encourages  tha  production  of  *  mart  act*  cooing. 

4.3  Ada  prograM  do  not  see  to  oa  any  nara  raadabla  than  Mlv* 
and  Algol  6S  progems.  T»r«  ara  asvaral  problaa  araaa: 

Saparata  conpUation;  an  (over-)  abend anca  ot  blocs  seclacatians  itoc 
local  data:  gvnaral  varboaiey. 

4.4.1  Ada  would  •j*k»  no  irtoupatibUities  In  interfaces.... 

4.4.2  All  ayanaaa  ara  notoriously  non-portable,  avar  if  written 
In  a  portabla  language.  Ada  Mould  cauas  a  couplets  ravaraal 
in  this  brand. 

4.5.2  lack  of  rafarancaa  (to)  static  lobjuctsl  is  a  ftmnaanri) , 
and  aarioua.  problaa. 
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2. 1  Tha  concapt  of  nadulaa  permitted  tha  daf inltion  of  constructs 
to  ba  locallaad.  (Prmlouely,!  aach  aaportad  construct  was 
avail abl*  throughout  tha  wtira  pragma. 

2.2  Tha  ganaraiity  of  tha  nodula  structure  panics  tha  hiding 

of  imaceaaary  dacails  froa  tha  intaxfaca  spacificationa  Basing  tbs 
ovarall  atructura  aaaiar  to  vndarstand.  Tha  distinction  bawasn 
tha  logical  prapartlss  of  an  abject  and  its  representation  wars  of 
halp  in  this  area. 

2.6  ...tha  ability  to  par  feta  information  hiding...  gcaacly 
facilltaca*  tha  r  sad  trig  of  tha  prograa  taat. 

4.1  ...prograa  will  taka  laaa  tiata  to  produce  in  dabuggaa  took... 
(bacauaa  of  that  oaeplece  control  ovar  inear facaa.... 

4.3  Tha  coda  is  nora  raadabla  nainly  due  to  tha  ability  of 
defining  eypas  with  wall  datiiMd  logical  propartiaa. 

4. 5  Tha  divsralty  of  features  offarad  by  tha  languaga  maa*  it 
difficult  to  aaka  a  cbsic*  in  curtain  eaaaa. 

4.6  Strongly  In  favor.  ...tha  fsaturas  ot  Ada...  saw  to  fit  tha 
dir  act  naads  of  tha  aabartrtart  ccaputsr  aoftwara  grotgi. 


2.2  Mac**.  Interfacing  batman  mits  was  c copies .  tore  cteplex 
and  error  prone.... 

3.1  No  reel  difficulty  using  or  applying  feet urea  cocractly  once 
they  ware  indeiacood. 

3.4  . . .the  nany  restriction*  and  qualifications,  mi  the  lack  of 

a  pattern  or  intuitive  parallel ra  ter  than  creates  a  buroen  tor 
tba  prograaasr .... 

4.1  Ada  is  sore  cosplea  then  any  otter  language  with  tdiicn  1  an 
faniliar. 

4.2  The  greater  pacification  of  data  and  the  need  tor  aeplicit 

cone action  of  types  is  a  nuisance.  lit]  addas  inexpectea  conversion 
errors;  fixed  point  arittestic  ess  a  sajor  prablte. 

4.3  No 

4.4  None 

4.5  foorer  quality  of  software  davslapsant  due  to  ceaplaeity 
of  Ada. 

4.6  ...Ada  is  Caspian,  award  and  iepnss*  unnecessary  txroana 
ipon  tte  programs*. 

4.7  The  deletion  of  red  indent  features  would  probably  iapair 
tte  usability  of  tte  language  for  many  progressed. 

4.10  It  is  difficult  to  identify  a  snail  basic  subset  within 
Ms  to  us*  as  a  starting  point  ter  learning  tte  language  ana  tor 
beginning  o  program  in  it.  Ada  tease  to  os  ssoe  ip  of  a  tec  ot 
Site- languages  that  are  partially  disjoint,  ratter  than  being 
concentric,  as  is  tte  lease  with  otter  prograaaing  languages. 
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2. 2  It  is  tetter  because  it  sore  clearly  saprsssss  ay  intent. 

2.5  Ns  prebite  -  infact,  it  was  a  relief  to  be  able  to  [translate 
to  Ads] 

0  ...Ada  wet  fowd  to  provide  tte  basis  ter  such  greater  esse  am 
clarity  of  foaulation  and  cctemnication  of  concepts.... 

...Ada's  expressiveness  will  contribute  substantially  to  software 
maintainability.... 
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4.1  ...we  doubt  that  debug  tte*  will  be  significantly  different.... 
4.4  an  increase  in  reliability)  possibility  of  re-using  cooe; 

decrease  in  dependence  on  proprietary  software. 

4.6  Apprehensive  at  tte  coteircial  risks  of  depending  on  as  yet 
unproven  technical  features. 
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0  Overall,  our  impression  of  tbe  language  was  a  very  positive  ona. 

3.3  There  were  two  major  omlesiona  f or  us,  variable  length  scringe 
and  formatted  1/C. 

4.1  ...Me  would  be  jmt  batter.  It  la  eo  much  better  than  languages 
aueh  as  fortran  or  aemnebler  language  am  to  sake  the  comparison 
laughable. 

4.2  ...a  very  useful  feature. 

4.3  fee,  for  a  number  of  reasons  including  enumeration  types, 
ability  to  overload  procedures  and  operators,  ability  to  have 
functions  returning  any  type,  and  etc. 

4.4  Love  it. 


•m  i3< 

2.1  that  can  be  done  [currently]  can  be  done  in  taa  with  only 
minor  codification. 

2.2  It  ie  possible  to  describe  tbe  ease  structure  in  a  mnrtac, 
nicer  and  sore  readable  way  in  Ma. 


2. 2  The  Ada  is  more  readable  than  tbe  assembly  or  tbe  flow  charts. 

4.1  Development  of  a  debugged  program  would  be  faster  then  in 
aneambly  language,  and  given  that  tbe  interrupt  priority  problem 
is  solved,  faster  than  in  fortran. 

4.2  ...Ada  esses  to  discriminate  by  requiring  tbe  fixed  point 
programme  to  live  with  stronger  typing  than  the  floating  point 
or  erect  integer  progrmmm  must  end*e. 

4.3  ...tbs  rest  of  tbs  language  is  almost  obvious  without 
explanation,  and  represents  a  viable  presentation  language  as  is. 

4.4  ...it  would  probably  be  easier  to  teach  bow  to  read  Ada  tban 

to  teach  the  struct*#  and  format  of  e  sizable  application  program. 


4.1  ...what  Ada  forces  you  to  do  is  to  ^mnd  more  time  in  the 
analyses  and  design  phases. 

4.3  It  looks  co  be  at  readable  as  moat  other  high  a  roar  languages. 

4.4  The  concepts  of  information  binding,  abstract  date  type,  would 
be  imad  extensively  —  thus  allowing  batter  defines  partitioning 
of  work. 
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into  Ada  is 


3.2  Mapping  an  witting  conetxrency  aecfaaniw 
difficult. 

4.1  Si  van  a  decent  progressing  anvlromant,  1  wouldn't  expect 
progrw  development  to  taka  any  longac  in  Ada  than  in  another 
high  otdar  language. 

4.2  The  Ada  coda,  particularly  if  formatted  proparly,  it  vary 
readable  coaparad  to  that  of  other  languages. 

4.4  The  use  of  Ada  would  benefit  our  project  in  two  majoc  ways. 
First,  Ada  has  several  [uaaful]  features.  Secern,  Ada  is  aspacteo 
to  be  a  Military  standard.  Our  wptrlwnral  worn  in  computer 
aactrity  will  thus  be  aore  easily  applied  to  real  progrws. 

4.5  verifiability  aay  turn  out  to  be  a  problw  for  aacurity  work 
although  it  aay  be  possible  to  generate  a  verifiable  subset.... 
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4.3  More  readable  than  Fortran!  1  Hot  necessarily  aore  resume 
than  Algol  SO,  but  this  aay  ba  a  fmiliar nation  problw.  Ui  tas 
thole  Ada  gives  a  good  algorithmic  description. 

4.4  Portability  of  mmericsl  software  across  aacAine  ranges. 
Debugging  and  error  detection  Would  be  aueb  easier  in  Aoa. 
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4.1  ...no  significant  difference  it  expected. 

4.2  strong  type  checking  is  important  not  only  fr  detecting 
programing  errors  but  for  snhancing  progrw  reaoaDility. 

4.3  aowsver,  Ada  code  is  iiriarscandable  by  anyone  mio  bee 
knowledge  (Halted)  of  Ada  constructs  or  good  knowledge  of  any 
other  HO L. 

4.6  Other  than  questioning  compiler  availability, ,  bullish 

4.9  As  a  general  rule,  the  progrw  and  oontrol  structures  of  Aoa 
are  goad. 
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3.6  Zt  did  sew  possible  to  write  clear  yet  efficiently  compilable 
code  wcept  in  isolated  instances.... 
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2. 5  Ada  is  not  the  kind  of  language  you  can  raao  a  manual  on  ano 
than  wsily  begin  generating  coda.  It  is  too  complex  for  that. 

3.6  I  do  not  feel  that  Ada  permits  vary  clear  expression  of  a 
progrw. 


4.1  Ada  is  tnnscessarUy  ccoplsa  and  restrictive.  tec  many 
aicmprocsa me  application*  1  feel  that  Asnablec  or  Fortran  would 
bt  bettor. 

4.3  The  nultitud*  of  progra*  types  sssas  artificial. 

4.6  I  would  not  lika  it  at  all  because  1  faal  that  Ada  in  it* 
peasant  for*,  i*  not  suitable  for  [syl  aicroptacaaaor  applications. 
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3. 1  Many  constructs  saa*  to  also  hawa  a  lot  of  actr*  keywords. 

4.3  ...prograi  readability  seats  to  be  significantly  laprovaa  over 
other  languages. .. .  Subpragraa  specifications  are  sots  easily 
understood  in  Ada  in  sea*  cases  than  in  other  languages. 

4.6  As  long  as  tbe  project  did  not  rsquirs  a  gram  osal  of  bit 
pattern  aanipulation...  doing  a  project  in  Ada  would  be  favor  so. 
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X.4  The  nusber  of  statosents  (and  typasi  should  be  such  the 
sasw.  The  area  in  tnich  the  Ado  will  require  sate  is  in  tbs 
declarations  and  the  amnt  of  visibility  allows.  Little 
experience  exists  with  the  coaploi  Ads  scoping  and  visibility 
rules.  This  is  an  are*  which  aay  add  to  th*  aaustananc*  eftort 
for  large  programs. 
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2. 2  'the  new  code  is  sore  ratable  at  th*  esecutahU  level  ana 
does  not  require  a  long  introductory  prologue  pc  warily  because 
of  tha  Ada  declarative  requirements. 

4.4  language  is  relatively  easy  to  lssrn  for  tbs  type  of 
language  features  required;  large  cfsn  data  blocks  will  be 
sioplsr  and  less  error-prone  with  control/ facility  of  packages 
and  ‘use*  statosents. 

4.6  ...I  would  wsIcqm  th*  opportunity  to  uas  Ada  in  an  asharmen 
software  jxojsct. 

4.9  Typing  end  packaging  features;  the  readability  um  traceability 
that  res ilts  is  worth  th*  additions!  efforts. 
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2.2  Th*  Ads  version  would  b*  assist  to  saint* in  since  the  coo* 
is  sore  descriptive. 

4.9  Ada  forces  a  sore  structured  software  design,  first,  an  an 
rwer all  program  level  by  Mans  of  th*  specification  section  am 
than  In  a  aoc*  data  Usd  body  section. 
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4.1  ...I  faal  that  tba  tib*  to  debug  a  pcogras  will  ba  laaa. 

4.3  9w  code  la  definitely  nca  ramble.  9m  pragrab  logic 
mi  Much  easier  to  follow  Mmh  it  cat  to  concutrant  tasks  aua  to 
ataf  ante  Much  facilitata  such.... 

4.6  1  would  look  forward  to  doing  ay  mat  abbaddad  coaputar 
project  in  Ada.  Although  it  raquiraa  soca  writing.  1  foal  in 
tba  long  rut  I'd  gat  tha  job  dona  aoonar. 

4.9  Although  acnawhat  tadioua,  1  would  not  Ilka  to  aaa  tha  typing 
of  data  chanjad. 
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2.6  9m  daaign  was  not  significantly  bat  tar ;  1  pc  warily  followao 
original  daaign  Milch  waa  aeructurad  and  nappea  aaaily  into  Aaa. 

2.7  Flamed  to  follow  original  daaign;  in  using  Aaa  1  founo 
sibpler  aachaniaa  and  constructs  in  acae  caaas,  a.g.  Initialisation. 

4.1  ...tha  nuMrous  programing  tachniguaa  availaole  with  Aaa  coulc 
■aka  prograb  nanagaant  difficult. 

4.3  9m  Ada  progran  was  dafinitaly  aora  raadabla.  Aaa  is  oafinitaly 
tba  aoat  raadabla  languaga  1  hava  ever  mcountarad. 
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3.6  1  hava  graat  caaarvations  about  tha  ability  to  optiaiaa  soa 
coda  as  tha  languaga  is  currantly  dafinad. 

4.1  In  ganacal,  I  think  that  Ada  facilitates  tha  progrw 
davalopaant  process.  It  is  difficult  to  naka  praaictions.... 

4.3  Generally,  m  Ada  pragma  in  not  vary  rMoabls:  daclaratxons 
auat  ba  presen  bottob-up;  begin-loep-select  osaanas  too  much 
nasting.  Separating  logical  declarations  frcb  physical 
rapraaawtatlon  pacification  it  awkward.  A  heavy  language  (no 
abbreviations) . 
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2. 2  9m  new  daaign  offer*  batter  protection  of  the  aata  objects 
because  of  tha  strong  typing  uaad. 

2.S  Two  aajor  areas  of  difficulty  had  to  do  with  handling 
ibceptional  conditions  and  with  caoosing  tha  bast  data  rapraaantationa. 

3.1  Surprisingly,  taat  layout  was  a  p*ot>l«b.  Ada  ooa*  not  allow 
presentation  in  top-down  faahion  (of  structures) ,  but  in  fact 
raguiraa  programac:.  to  perfotb  a  topological  sort  wo  that  no 
forward  rafarancaa  occur.  Not  only  i*  this  a  nuisarc*  to  tbs 


wtitar,  but  I  don't  m  it  u  uaaful  tot  tba  raadac . 

3.3  Thai  critical  faatura  hitting  In  Ada  tot  out  ((plication 

was  a  wall-dafinad  scheduling  policy  and  tha  lack  of  facilities 
tor  introducing  ont. 

4.3  In  k*m  way*  it  it  laaa  raadabla.  Tha  procedural  coda 

it  (robably  at  goad  in  Ada  at  in  other  high  level  languagat. 
Hon-procedixal  coda,  tuch  at  typt  dad  at  at  tons,  hat  a  vary  tavara 
r satrict ton  placod  on  iet  presentation.  Tha  no-foruaro-retacanca 
rule  anforcaa  tha  hottest  up  ordar. 

4.4  The  pnttibility  of  dattgning  all  intarfacat  and  ccapiling 
than  indapandantly  of  iaplanantationa  will  ba  a  plut. 

4.4  I  would  not  ba  reluctant  to  uta  Ada  on  production  prograts. 

I  think  it  is#  in  tha  larga#  a  well-conatructud  languaga. 
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3.2.1  Accaaa  typaa  could  hava  baan  usad  to  graatly  iaprove 
accaat  performance  but  thay  ata  not  capable  of  denoting  static 
variablat. 

4.4  Tha  Ada  toutca  coda  would  ba  salf  docuatnting  ana  such  aastar 
to  raad  and  follow.  A  maintenance  prograaMt  would  hawa  a  graatar 
undar standing  of  tha  prograt  with  last  effort. 

Ada  promotes  top-down  structural  programing. 

Tha  job  of  transporting  programs  fraa  ant  machine  to  anochtr  wouio 
ba  atsiar. 

Strong  typing  would  prevsnt  subtle  typa  atroct....  pacicagat  will 
prevent  procaduraa  fraa  accosting  and  aaoifying  data  that  thay 
should  not  hawa  accata  to. 

4.4  Ada  it  a  vary  capable  languaga.  It  permits  goad  ttructutta 
coda  and  tha  strong  typing  htlpt  tain tain  data  integrity.  At  XL 
would  Ilka  to  uta  Ada  in  futvra  projactt.  however,  inafficianciat 
in  tha  languaga  aty  torca  tha  continued  uaa  of  JOVIAL  for  coal 
tiaa  applications  unlatt  tha  probltat  act  caaolvao. 

The  graatatt  concarn  it  with  accatt  typaa.  Tha  basic  cone  apt 
it  amcallent  but  tht  asaociatad  problem*  aako  chaa  of  liaitaa 
value  tor  ATAL  applications. 
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4.0  Orarall  iaprattlont  of  tht  Ads  languaga  act  vary  favorable. 
Tha  packaga  concept  it  ptchapt  tht  claanaat  solution  to  aata 
tor  tha  development  of  ganartl  pirpoaa  library  routines. 

Thara  was  no  aiflor  difficulty  in  laarning  to  uta  a  convtmant 
tubtat  of  Ada.  Tha  only  significant  pr oblast  ancountacao  wata 
in  tha  tasking  facilitiat. 

Ada  it  an  amtramtly  vacboaa  languaga. 
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2.2  Farcing  the  uh  of  Ada  and  thereby  the  Interfaces  sqpportao 
by  the  Ada  runtime  systm,  contribute*  to  Bating  an  applications 
progras  aer*  manageable. 

2.7  Originally  sane  of  the  data  was  represented  by  enumeration 
types,  but  dim  to  tbs  limited  nuabec  of  operations  the.  coulo 
be  perfooMd  with  enuearation  type  data,  recora  and  array  structures 
war*  cbossn  instead. 

4.1  Ada  aay  have  an  advantage  in  tba  debugging  area  because  of  its 
readability  and  because  aost  programs  written  in  it  tsno  to  be 
structured  an  that  it  is  not  difficult  to  follow  tbs  pstn  of  oats 
through  a  prog ran. 

4.4  Ths  greatest  advantage  accrued  fro  use  of  Ada  on  a  {reject 
would  probably  b*  progra  aaintainability. 

4.9  9m  data  structures,  pregran  structure  and  separate  compilation 
facility  in  Ada  are  its  pr uae  assets  as  progressing  tools. 
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4.9  I  particularly  Ilka  the  ability  to  restrict  visibility  in  Aoa 
progrmu,  because  I  haw*  wotted  on  projects  wnere  thia  feature 
would  have  prevented  pr  oblast  caused  by  multiple  programmacs 
making  multiple  uses  of  a  particular  data  field. 
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2.2  9m  nsv  design  is  mors  portable  because  the  rascal  version 
had  to  ua*  non  standard  I/O  procedures.  9m  new  assign  is  macs 
efficient  thanks  to  amcsptioo  handling  for  errors  ana  emits  in 
the  middle  of  loops.  9m  new  design  is  assist  to  moat stana 
and  uses  Mured  packages. 

4.1  Although  ada  it  slightly  nore  verbose  than  Pascal,  am  would 
therefore  require  more  original  coding  work,  it  would  take  loss 
time  to  develop  a  debugged  Ada  program.  This  is  be  because  Aoa 
it  easier  eo  understand,  and  it  has  wore  safety  features. 

4.3  Ada  t*  aueh  more  readable  than  otbac  languages. 
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4.0  Our  Impression  of  Ada  was  that  it  was  an  asoeedingly 
coaplam  Language.  He  now  feel  that  although  it  la  coaplam,  me 
is  nor.  significantly  aore  so  than  several  other  taOLa. 
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0  ...with  the  mxoftuu  cfaang*  [interrupts)  to  Mat  cm1*um 
regutr  Merits,  w*  given  Ms  an  *A*.... 

On*  em  hardly  imagine  a  b*tt*r  conceptual  modeling  tool  than 
Ma  tasking,  but  the  napping  into  inpl  Mtntation  aaans  latent 
with  difficulties. 

4.3  Another  amphatic  y*a,  primarily  becauee  it  reads  nor* 
lilt*  English  test  than  a  progran  language. 

4.10  Wa  like  Adei 
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4.4  I  believe  that  using  ada  will  gaed  19  project  cospletion 
and  reduce  costs. 
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4. 1  1  would  any  that  a  debugged  Ada  would  teas  lass  tine  to 
develop  becaua*  type '  Checking  would  ensure  clean  interface*  arc 
avoid  type  muting  (producing  garbage!  • 
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2.2  New  design  considered  conceptually  clearer  becatiee  of  fewer 
interfaces  (subroutines)  where  actions  tan*  place  ramotely. 

4.3  th*  standard  par  11  age  with  nan  for  all  character  eases 
progress  of  this  type  sore  portable.... 

4.4  Dimension  analysis  problem  caught  at  ccmpile-tim#. 
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2.S  In  general  the  design  sapped  easily,  lh*  areas  of  troUsle 
were  machine  dependent. 

3.1  Finding  tha  best  My  to  divide  a  pcograe  up  between  pac rages, 
procedures,  and  tasks  was  tha  prablaa.  This  will  require  a  outer  ant 
design  outlook  than  we've  used  in  th*  pest. 

4.1  Ade  would  simplify  tha  imp) Mentation  of  dabuqgea  coo*  to 
specification.  Ma  would  allow  testing  tatter. 

4.4  The  parallel  tasks  of  Ada  would  simplify  tha  design  of  ccmplm 
machine  aimul'jtlons.  Oil*  wss  a  problem  in  tha  current  system. . . . 

Tha  convolutions  which  wart  necessary  for  this  wets  unbelievable. 

Tha  recursive  nature  of  Ada  would  allow  easier  implementation  of  team 
algorithms.  We  can  obviously  do  tha  calculations  non-tec  actively 
but  not  as  neatly. 

4.3  Ma  Would  (help)  by  allowing  ua  to  design  stanoaro  convention* 
at  a  high  level  in  packagaa  and  than  requiring  the  at  of  comet 
definitions. 


4.4  Ada  would  mike  life  easier  by  allowing  us  to  define  tbs  oata 
ad  processing  interfaces  la  tbe  early  conceptual  design,  am  tnan 
iapl«MRC  tba  dacalla  within  thaaa  constrain t«.  Also  tba  review 
of  pragrm  design  and  aeyla  would  ba  aaaiac  in  Ada  bacausa  of  its 
structure  and  readability. 
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3. 3  There  ia  no  question  that  tba  radeaiqn  is  batter  than  tre 
original  in  sany  way*  —  conceptual  simplicity,  raahaoU.it> , 
maintainability,  modularity,  machine  independence,  ate. 

2.3  Tba  task  facility  ia  a  natural  for  this  application  oeapite 
the  (priority]  flaw.  Tba  use  of  packages  and  tasks  provides  an 
affective  mans  of  decoding  the  different  parts  of  the  system. 
Abstract  types,  especially  antaaratad  types,  ware  useful  in  seeing 
tba  dasigrn  me  readable.  Representation  specifications  ware 
affectively  employed  to  eliminate  obscure  bit  mmipulation  am  to 
make  tba  thole  design  leaa  machins  dependent 

2.4  The  representation  specifications  enable  the  reoeeign  to 
mart  tba  storage  requirements  of  tbs  application. 

3.1  Toe  inability  of  tba  task  facility  to  suspam  am  resuae 
background  lor  lower  priority)  tasks  to  service  higher  priority 
tasks  is  viewed  as  a  severe  liaitat.  x>. ... 

3.4  Hy  only  coicarn  for  tbe  opt im nation  of  any  construct  in  ay 
program  ia  tbt  optimisation  of  tasks.  The  haasi  and  hanarman 
(taebniqua)  tom  premise . . . . 

4.1  Any  increased  time  gpant  in  coding  an  Ada  prograa  is  sore  tnan 

offset  by  reducing  problems  due  to  type  minrrnaa  am  proceoure 
interface  siaaatcbes,  casm  sources  of  prablaaa.  In  addition, 
programs  tn  Ada  are  definitely  more  reedaole _ 

4. 3  Tba  Ada  progras  is  more  readable  than  tba  original  program  in 
every  possible  way!  By  using  abstract  types,  especially  emasarat aa 
types,  tbe  (rogemasr  can  produce  a  program  that  ia  more  oaactiptive 
and  problmi  oriented. 

4.4  The  advantages  of  Ada  ate  many  and  well  known:  machine 
independent;  more  readable  and  maintainable)  more  reliable)  structured 
prograa  design. 

4. 9  I  am  vary  enthusiastic  about  the  whole  language.  In  particular  s 
tba  separation  of  tba  logical  md  physical  properties  ot  a  program  act 
supported  by  the  language  syntax)  despite  the  flaw  d recover eo  in  the 
task  facility  (ass  Response  3.1),  the  teak  facility  provides  an 
aacellent  conceptual  approach.... 
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2.2  the  new  design  is  batter  than  the  original  design  because  the 
Ada  design  is  structured....  The  use  ot  Ada  reduces  the  volute  ot 
source  coda. 


2.3  The  Jtd*  tasking  eonopt  so  naturally  fitted  the  prrtlna 
the'  it  mi  iapoaaibl*  to  conceive  of  any  other  approach;  generics 
appaatad  natiral. 

4.1  9m  language  to  naturally  supports  tasking  (logical),  that 

ay  only  cdiplaint  ia  that  tbara  it  a  hit  of  conceptual  overloading 
of  tha  tans  task. 

4.2  In  addition  to  detecting  type  arroca  at  cnaptla  tins,  Aoa 
forces  an  aa.  ly  focus  on  data  as  a  general  thing  to  be  oaaignoD. 

4.3  Ma  ia  vary  readable  bacauae  am  ■■ration  types  fit  ao  naturally 
into  prablaaM. 

4.4  Advantages  fr<M  using  Ada  are  probably  going  to  e-as  fraa  its 
readability  initially,  and  portability  in  tha  longrun.  Other  areas 
Mtere  Ada  spears  valuable  are  note  aiotle.  It  **«■*  reasonable  to 
aspect  the  quality  of  Ada  code  be  better  than  other  languages,  the 
use  of  Aaawbly  code  to  be  reduced  and  to  asa  sore  attention  to 
data  design. 

4. 5  9m  advantages  aay  be  offset  by  Ada1  a  tdnlenees.  A  proqr— «r 
auat  understand  concurrent  processing  to  unacstand  tasking,  macro* 
to  me  generics  and  ‘typs*  to  cade  at  all. 
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2.4  Using  tha  Ada  language  resulted  in  a  better  design.  lb*  typing 
of  each  object  gave  sore  information  about  tha  aata  being  ueeo. 
bmeerated  typing  encouraged  aore  descriptive  eeeignaants.  Ibe 
■i sines  of  the  language  added  to  its  readability. 

4.4  Ada  could  be  uaad  very  effectively  aa  a  design  language. 

9m  language  requires  e  strong,  clear  specification  of  all  tha 
objects  being  used.  9m  readability  aurpeeeee  eoet  iall2)  other 
languages. 
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2.2  tkrae,  on*  MU  star— ant  had  eo  be  inucducad  ftar  a  label 
in  order  to  avoid  assigning  tha  label  to  tbe  following  PLfc  .  -  U/uk 
etataaent  and  than  having  to  spur  local y  repeat  tha  latMl  in  rne 
EC  LOOP  states  ant,  Miich  would  have  eado  tha  prograa  aoca  oifticult 
b>  saints in.;  but  batur  In  sane  r aspect a,  such  as  there  are  no 
ano nyeoua  OC  ststesents ,  there  are  aany  fewer  MUUm  than  in  Pascal 
because  Ada  provide*  tha  OC  IP  Milch  is  Biasing  in  Pascal. 

3.6  Not  ae  clearly  or  as  concisely  as  in  Pascal. 

4.4  At  present  Ada  is  incapable  of  exporting  tha  applications 
we  are  interested  in.... 
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2.2  The  new  design  it  mors  straight  forward  and  far  more  reaoacle, 
possibly  at  ths  cost  of  iramnty  spac*.  It  is  hopao  that  cm  toe 
varsion  say  ba  abla  to  execute  slightly  faster. 

2.3  The  general  goal  of  the  Steelman  requirements  for  sore 
readable,  more  easily  maintainable  cade.  It  is  significant  cnac 
in  trying  to  understand  the  asatMer  version  in  oroer  to  reoesign 
it,  two  relatively  major  flams  in  the  logic  were  discovered  tfiicn 
could  return  erroneous  data  in  some  circuastances.  it  is  felt  that 
this  would  not  have  happen*!  in  Ada. 

2.6  The  problsm  in  the  past  has  been  twisting  the  trogcms 
Development  language  around  to  match  the  MOL. 

4.0  AMY  good  structured  design  could  be  very  easily  implemented 
in  Ada.  On  the  other  hand,  a  non- structured  design  wouio  oe  naroer 
to  isfil  eeenr  the  program  evolves  easily  from  the  fresn  design, 
however,  it  is  not  at  all  easy  to  transliterate  frcm  an  unstructured 
existing  SOL. 
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1.0  It  is  felt  that  Ada  should  receive  additional  usw  for  redesign 
and  develoiment  which  concentrates  on  Orderly  Development  or  rmiiacis 
Software  for  Systems  with  mV-erWeri  computers;  Enhancing  am 
clarifying  Ada  semantics;  Simplifying  Ada's  syntax;  Incorporating 
additional  real-time  capabilities. 

3. 0  Ada  syntax  is  extensively  verbose  and  in  many  cases 
grammatically  incorrect. 

3.1  Access  types  and  allocators  are  very  difficult  to  understand 

and  uae. 

3.2  The  IT -statement  nested  with  itself  and/or  loop-statements 
crested  unexpected  difficult  ipon  application,  hany  levels  of 
nesting  were  virtually  ixi intelligible.  With  each  level,  confusion 
increased.  In  following  the  logic  of  the  pragma,  one  is  never 
guite  sure  where  one  series  of  statements  ends  and  another  Dag  in*. 
Additional  commenting  was  necessary  to  help  alleviate  these 
problem.  Debugging  it  difficult  at  beet. 

4.1  Developing  a  debugged  program  with  standard  I/O  requirements 
would  tabs  no  longer  nor  Xnrter  in  Ada. 

4.3  Ada  produces  less  readable  code  than  other  high-level 
languages.  Verbosity  seams  to  be  the  keyword.  Ada,  in  its  attempt 
to  provide  more  readable  code,  has  gone  to  the  other  extreme. 
Additional  keywords  are  attactmd  to  basic  pragrmi  constructs  which 
ere  unnecessary.  They  convey  no  additional  significant  meaning 
that  could  not  be  picked  ip  by  the  use  of  delimiters. 
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4.1  I*  ret  believe  chat  using  Ada  instead  of  Concur  rant  Pascal 
will  incraaaa  dwralagaant  tiaa. 

4.2  A  nuabar  of  pragraaaing  actors  war  a  detected  by  the  Aoa 
last  Tranalator 

4.3  The  Ada  eource  coda  it  ascapcinnally  claar.  X  hav*  fait 

Chit  tay  about  every  program  I  hava  written  in  Ada.  however  ,  itiusj 
depends  on  tha  idancifiart  and  constructs  uatd.... 

4.4  Ada  could  ba  utad  to  davalop  an  antira  tyttaa,  eliairiaung 
tha  naad  for  atcataiva  aacftina  coda  oc  asaatbly  language 

intar t  ion* ,  and  would  thtrafor*  incraaaa  productivity  am  raauc* 
tha  cotct  aaaociaead  with  prograa  aemtanance. 
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2.4  1  do  rot  faal  that  knowledge  of  Ada  halpaa  a*  arrxva  at  a 
battar  daaign  but  tha  languaga  allowed  aa  to  rapcaaant  tha  oatign 
battat  in  prograa'*  lap)  — nri~i  ir  tha  progran  atructura  Dacaaa 

aora  cloaaly  tiad  to  tha  functional  requixmnts  of  cna  pcocuoa. 

2.  S  The  translation  of  tha  aathbantics  in  tftit  exanpla  Iron  a 
specification  into  tha  Ada  languaga  was  axtraaaiy  ttraagnt 
forward;  However,  using  tiaa  Ada  fixer  point  capraaantation 
would  probably  aa  wch  aora  difficult. 

2.1  .. -paexagat,  aocaas  typaa,  and  ptivaea  typat...  tnoula  aaaa 

(our)  programing  gob  required.... 

2.6  A  knowledge  of  Ada  did  not  produca  a  battar  aasign  aa  wa  oao 
hoped.  ferhape  if  wa  could  obtain  a  battar  unbar  teaming  of  now  to 
usa  accaat  typat.  wa  bight  find  a  my  to  auccastfully  uaa  tnaa  to 
laprove  tha  currant  daaign. 

41.  ...writing  progrms  will  take  longer.  There  it  aora  arrot 
enacting ,  out  tha  languaga  conaaquantly  raquiras  a  graat  aaal  aora 
writing  affort.... 
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2.2  Tha  naw  daaign  it  such  aaaiat  to  raad.  It  haa  a  aora  logical 
downward  flow. 

..3  Just  aa  Jaw  Ichbiah  aantionaS  at  tha  Ada  Orientation,  you 
can  actually  raad  an  Ada  prograt. 
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4.C  Aftar  allowing  for  fwlliarixation  with  Ada.  I  baliava 
developing  a  dabuggad  prograt  tlailar  to  aina  woula  tana  lass  cuts 
in  Ada.  This  would  ba  a  casult  of  tha  ability  to  datact  progressing 
arrort  and  moroutina  'ntarfaea  inconaittanciaa  at  coapila  urn. 

Tha  strong  type  checkin?  of  Ada  that  caquirt  greater  specification 
of  data  and  its  usage  it  needed  for  aabadded  tyttaas. 


4.3  The  Mi  coding  is  written  in  note  of  an  engliso  amc  wrsicn 
bmi  it  Malar  to  understand. 

4.4  With  Ada's  data i lad  data  typa  definitions  and  its  nat  tin* 

type  stocking  and  structured  pcogramaing  architecture  sore  praolms 
win  ba  alininatad  in  tto  design  and  oabug  phases  ot  pcogran 
development.  This  *»uld  reduce  tto  problems  in  tto  verification 
and  validation  phases. 

4.3  It  will  ba  vary  difficult  to  convart  tto  axisting  MEUkPLAJ,  coo* 

without  a  Mjoc  redesign .  It  is  not  struct ucao  in  tna  tonal 

Sanaa  and  doaa  not  flow  from  top  to  boteea  aa  Ana  program  ausc. 
...a  sajor  radasign. . .  is  almost  mandatory.... 

4.10  Tto  Ada  languaga  is  carta  inly  a  languaga  of  tto  lSeu's. 

Its  atructirad  and  highly  readable  constructs  will  provide  cnaapar 
and  aora  reliable  software  in  tto  futurt. 
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C  My  asparianca  with  Ada  has  basn  disappointing.  It  is  a  wall 
thought  out  languaga  uaaful  in  a  taacning  anvironaant  nut  ot 
limited  valua  for  uaa  in  mall  real-time  computers.  Ito  two  nag  or 
flaws  in  tto  Ada  daaign  art  its  isiueual  oalta  oc  fizaa  typa 
var labia  notation  and  its  coapiaa  intarfaca  witn  laamrly  languaga. 

2.S  in  general,  Ada  is  a  aladga  hmanr  mars  only  a  tae*  naanar 
is  toad  ad.  It  aamsd  to  taxa  aora  tins  to  sat  up  a  pracanura  am 
coda  its  ocular  plats  specification  than  to  actually  oataiop  ana 
inplmant  tto  caal  operation. 

4.4  Tto  mtra  tins  it  would  consuto  would  not  aato  it  wortmaiUa. 
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4.1  ...coding  would  certainly  ba  dona  quicker  in  Ada.  Tto 
debugging  proceas  would  probably  ba  quicxar  for  an  aseeamly 
languaqa  version. 

4.3  If  astansive  nesting  of  different  types  of  aadules  is  aane. 
tto  progras  can  ba  vary  confusing. 
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2.3  Tto  vprnpr  lateness  of  tto  Ada  record,  aggregate,  ana 
peerage  constructs  for  this  application  Bade  thm  convenient 
cmdidates  and  therefore  thee*  concepts  influences  tto  reassign 
significantly. 

2.  S  Much  of  the  redesign  was  accospl  iatoo  with  certain  Ada 


feature*  in  Mind.  However ,  ifttc  eta  tOL  was  written,  it  was  vary 
easy  to  translate  eta  FOL  directly  into  Ada  code. 

2.6  In  aany  cases,  tia  Ada  construct,  were  very  acpropriata; 
i.e.  aggregates,  records. 

4.1  lhe  specific  problas  could  have  been  resolved  in  a  shorter 
else  by  using  languages  with  constructs  similar  to  Ua  SOiSCelK 
attributes,  entities  and  sets,  although  this  language  would  lacs 
scae  of  the  highly  desirable  features  of  Ada, 
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2. 5  ...we  couldn't  figure  out  how  to  do  suing  conversion  in  ao*. 
2.7  We  changed  several  of  o tv  design  ideas  curing  the  nos  cooing 

primarily  to  cant  advantage  of  the  advanced  features  of  Ada  ano 
only  once  to  escape  a  serious  difficulty.  9a  specific  feature 
that  had  tta  strongest  influence  on  our  redesign  was  passaging 
and  visibility  rules. 

4.5  ...I/C  in  Ada  stent  to  be  eitner  sadly  1  acting  or  at  ieaat 
badly  explained,  especially  for  input  ASCII  suing  conversion. 
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2.6  Having  teiowladge  of  Ada  done  help  to  arrive  at  a  Darter 
design.  This  was  illustrated  by  the  history  of  ay  reassigns.  *e  ay 
understanding  of  Ada  increased ,  so  did  the  quality  of  ay  assign. 

4.4  It  is  likely  that  the  consequences  of  changes  to  Ada  prograa,* 
will  be  acre  quickly  and  accwately  imdarstooo  man  lor  progress 
written  in  other  languages. 


